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SUBJECT : CYCLE 3 REVISION _OF_THE pRoc EQURES NOTEBOOK 


A Cycte 3 update of the Integration Procedures Notebook is 
now availablee The Notebook has not changed a great deal 
since its extensive revision at Build Qs but there are some 
changes of interest in the utility procedures,» described in 
Section 2.ll»s and the cYBIL bultd processs described in 
Appendix C. Keypoint information has been added to the 
document in Appendix Dez A complete jisting of this document 
can be obtained through the following command sequence: 


ATTACHs I PNDOC/UN=DEV1. 
SESePRINT IPNDOC 
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1.0 NOSZVE_SYSTEM_ OVERVIEW 


lol INTRODUCTION 
The basic components of NOS/VE include the following: 


- <A Hardware Initiatization Verification Sequencer 
{(HIVS) component 

- Modifications to standard A179 NOS system components 

~- A170 NOS application programs (and procedure files) 
which execute in the A176 NOS (Real State) 
environments and provide system to system 
communication facilities. 

- The Virtual Environment code which is responsible for 
the execution of tasks in Native Mode in the Virtual 
State of the hardware. 


The nomenclature used to describe NOS/VE components is 
rather confusinge Frequentlys the Virtual system software is 
what is referred to as "NOS/VE",. When A170 NOS and the 
supporting utilities are presents the term “Dual State" is 
usede To differentiate the two execution modes of the machine 
the terms "Native Mode™s "Virtual Mode"s and "Virtual State" 
are used to describe the execution of C180 instructions. The 
terms "Real State" and "NOS" are used to refer to the 
execution of C170 instructions. 

The model which is often used to describe the execution of 
NOS/VE in Dual State mode is that of one machine front-ending 
anothers and communication between the two machines occurring 
over a communications link. From the software's point of 
views, another perspective is used. To the Virtual State 
software, the NOS system is merely a job which happens to be 
executing in the Virtual State envelope created by EI. (The 
microcode transtation of the ¢€170 gjinstruction set is 
"invisible™ to both the NOS and NOS/VE software.) NOS's view 
of the Virtual State is merely that of a job which runs at a 
control points and Is communicated with through the 
K-dispiay. The remainder of this section is meant to describe 
NOS/VE with regard to its components. 
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lelel THE HIVS COMPONENT 


Included in the diagnostic worlds which establishes the 
initial Virtuat Execution environments Is the microcode for 
the CPU as well as a Native Mode monitor-like program called 
the Error Interface (EI). The microcode Is strictly supported 
by the diagnostic organizations, and neither the NOS nor the 
NOS/VE software will execute without microcode present in the 
CPU. The EI program is supported by Advanced Systems 
Development. There are currently two versions of EIs one 
which onfy supports A17G NGS and does tasks such as CMY 
instruction emulations, and one which also supports the 
switching between the NNS and NOS/VE CPYy monitors. This 
fatter version of EI requires a partner intermediary called 
the NOS Trap Handler which Is statically toaded with the 
Virtual State softwares and is toaded during deadstart of 
NOS/VE. In order to assure that the right version of EI is 
presents the HIVS tape which is distributed by Advanced 
Systems Integration for us2 with NOS/VE is the correct version 
to install. 


1.1.2 A170 NOS MODIFICATIONS 


The modifications required to support a Dual State 
execution environment are primarily assembied in the BLD170 
procedure file, Few specifics will be given here other than 
to state that half a dozen Peripheral Processor routines are 
involveds as well as modification to NOS CPU Monitor. The key 
aspect to note about these components is that a special 
version of A170 NOS deadstart tape must be used. <Agains this 
deadstart tape version is supplied by the Advanced Systems 
Integration project, There are additional procedure fiies 
which must atso be present on this special deadstart tape» 
which are not documented here at this time. 


1e12-3 A170 NOS APPLICATIONS 


A portion of the software alluded to as A170 NOS 
modifications could be classified as A170 NOS Applications. 
The applications referred tos however» are not present on the 
deadstart tapes but exist as permanent files which are invoked 
or processed by procedure files present on the deadstart 
tape. In the strict sense of the words those utilities which 
are not execution order dependent or require system residence 
are placed on the deadstart tape. Utilities which must be run 
in a given sequence (and possibly as system origin) are 
governed by procedure files which are present on the deadstart 
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tape, 


1.1.4 THE VIRTUAL STATE COMPONENT 


The Virtual State software consists of both a statically 
and dynamicatly tinked component. The statically tinked 
component is composed of Monitor and Task Services modules 
while most other tasks are dynamically linked. In order to 
staticaitty link Monitor and Task Servicess the SES utilities 
VELINK and VEGEN or thelr Virtual State equivalents must be 
used, In other systems this statically tinked system 
component is commonly referred to as the "unconfisgured 
deadstart tape” or "bootstrap system". Qnce the "bootstrap 
system" has been generated which has Its own LINKER/LOADER 
equivalents then it is possibfe to deadstart this bootstrap 
system and begin dynamic link/loads. One of the attributes of 
this statically tinked component is that there is more than 
one partition associated with it. In order to keep these 
partitions separate during the CI build processs these 
partitions are placed on separate files. The content of these 
partitions Is described in a subsequent section of this 
document, 

The dynamically tinked component of the Virtual State 
software consists of [I format object text which is processed 
by the NOS/VE LOADER. In order to create II format object 
texts it is necessary to either use the utility "CITOII" to 
convert CI object text to II object texts or else use a II 
compiler or assembler. In order to nake this CITOIIL uttitity 
available to each task created by the Virtual State softwares 
the object text for this utility nust be staticatty tinked and 
foaded with Monitor and Task Servicese. Once this utility Is 
Made avaifable to dynamically generated tasks, it is necessary 
to retrieve the other utilities which establish communications 
with their A170 NOS counterparts. This is accomplished by 
executing a post-deadstart SCL procedure file which Initiates 
the Remote Host and Interactive Facilities from the tibrary 
“OSLIB" (which in turn was created from the CI object text 
file "XLJOSL"). 

The components mentioned thus far have been the statically 
linked modules for Monitors Task Servicess the CITOII utitlitys 
and the dynamically linked nodules from OSLI8B. There are 
libraries other than OSLIBs, some of which are necessary for 
the successful execution of user taskse Such a tibrary is 
SYSLIB which contains the Object Code Utility modules which 
provide for the creation of II object text Jtibraries. The 
SYSLI8 UYibrary must be made part of a job's object tibrary 
fist aif any II object library manipulations are to be made. 
Fron the compiler perspectives, the run-time libraries CYBILIB» 
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MATHLIBs FRTLs etc. must be created by a job which has SYSLIB 
as part of its object tibrary tist.e. The complier generated 
object text for a compiler such as CYBIL names the appropriate 
run-time tibrary ijn the object text records (eg. CYBILIB). 
Thuss a CY3YL program must access the appropriate run-time 
fibrary (CYBILIB) and make this tibrary part of the job's 
object tibrary tist. This explicit manipulation of a é§job'’s 
object tibrary fist will eventually be replaced by job 
prologues which are created during accounting and validation 
and/or user protogues which establish a job's execution 
environment. 


162 VIRTUAL _STATE_ PARTITIONING 


Bulild Q reflects Phase 2 of the restructuring of the NOS/VE 
operating system into two distinct partitions - the system 
core and the job template. This restructuring is necessary in 
order to reach the R1 goal of deadstarting NOS/VE in IMB) of 
memory. In this system the system core will be able to 
deadstart and support taskings withoyt the Job template. This 
was compteted in Build P. 


The system core contains monitors the NOS Trap Handlers and 
all code that executes in ring ls and consists of the 
following tibraries: 

XLMMTR = Monitor mode procedures. 

XL$113 = Job mode procedures that have static datas write 
Mainframe Wired, Mainframe Fixed or Job Fixeds or 
make privileged monitor calls (these are most of the 
modules that used to reside In XLJL1LF).- 

XL$133 A smali subset of the procedures 

XLS123 ~ that used to reside in XLJ12F>» 

XL$130 XLJ13F, and XLJI1FF that are 

XLS10D needed by the system core, 

In the restructured systems modules in the system core cannot 

XREF variables ofr procedures that are part of the job 

templates and indeed need not know nor depend upon any job 

template code. The job mode segments that come from the 
system core wiltl be in the address space of every task 

(regardiess of job type) and will have the same segment 

numberse Code cannot be added to or deteted from the system 

core without a deadstart. 


Alt the rest of the operating system code that does oot 
reside in the system core is found in the job template. This 
code consists of Job Monitor and ring 3/run anywhere’ task 
services,» contained in the following tibraries: xXxLJ223, 
XLJ23D» and XLJ2DD (xXLJ236 and XLJ266 are tinked ins but are 
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empty in Bulld Q)- In the restructured systems there may be 
multipte Job templates depending upon the specific 
requirements of the various jobs in the system. These job 
tempiates will be staged across the memory link after the 
system core has been deadstartead. 

The modules on file XLJB8B consist of user tasks which can 
be thought of as belonging to a third type of partition. This 
latter partition contains routines which run In job mode in 
the user ring (for the purpose of converting CI compiler 
generated output into II format after it has been transferred 
fron the A170 NOS software to the NOS/VE execution 
environment). In the memory maps which Is described in a 
subsequent sections the code for this user partition resides 
in the “User Task(s) Library” and is made a part of each task 
created for NOS/VE. The system restructure which occurred 
with Build M made this partition relatively small (since this 
partition must be loaded into memory at deadstart time). 
Although the build procedures allow for this partition to te 
replaced with one which contains additional user tasks» the 
preferred method of executing user tasks is to GET them from a 
NOS permanent file (after they have been generated by a CI 
compiler) to the NOS/VE execution environment and EXECUTE 
these tasks using the NOS/VE LOADER. If the execution 
environment is the simulator instead of the hardwares then new 
user tasks should be statically toaded in place of xXLJBBB 
using the NVELINK procedure. 

Any XDCLYNnd symbol within a given partition can be XREFfd by 
any module within the same partition. To allow other 
partitions to XREF these same symnbolss the symbols must be 
gated. Gating a symbol onty makes the symbol! available to 
other partitions during the Ilinking oprocessys it does not 
necessarily mean that the xXDCL*d tocation can actually be 
referenced ~- that is controlted by the ring brackets. In 
generals only selected XDCL'd symbols are gated. A variablie 
or entry point may be gated in thea source specification using 
CYBIL and CPU ASSEMBLER tanguage constructss or the object 
text may be modified by using the SES Object Code Utilities. 
Refer to the MAPXX files produced by the NVELINK procedures 
for a fist of the entry points available to a user taske A 
convenient tisting of these entry points can be obtained by 
running the MAPXX tinkmap file through the procedure NVEMAP 
and specifying the keyword "TWO". The gated entry points are 
flagged in the section entitled "PVA» NAME SORTS" at the end 
of the NVEMAP ftinkmap output. The NVEMAP keyword "GATED" will 
fist onty thoses entry points which are gated (see the 
documentation for the procedure NVEMAP in Section 2 of this 
document de 

Occasions arise in which procedures are of common utility 
to more than one partitions but should not be gated across 
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partitions. In such instancess these procedures are placed 
upon a "run-time" library such as CYBILIBs and references to 
these procedures are satisfied at "LOAD" time from the 
appropriate tibrary.e. "LOAD" time satisfying of externals can 
either be done statically or dynamicatty. A static toad is 
accomplished through the SES Linker and Loader utilities. 
Dynamic loads occur through the use of the NOS/VE toader 
during the execution of a C189 job. Whenever possible» 
dynamic tloading of routines is preferred (as in the case of a 
compiler satisfying externals from a run-time tibrary) since 
this is the mechanism which customers of NOS/VE systems will 
be using. 


1.3 MANLPULAIION_O&_NOSZVE_PASTITIONS. AND LIBRARIES 


When bullding a systems monitor must be ftinked first. All 
gated symbols within monitor then become available to task 
servicess which is linked second Although some monitor symbots 
can be referenced by task services» the only way to execute 
monitor code is via the exchange jump ~ i-ee@es the CALL/RETURN 
mechanism is not valid for use between monitor and job modes. 
User tasks are ftinked last and can reference gated symbots 
defined in task services, It is important to note that 
although the linker will allow a reference to a given symbol» 
the ability to actually reference the tocation is determined 
by the ring brackets on both ends of the reference. 


1% QUAL_STATE MEMORY MAP 


When dealing with a virtual memory system it is often 
necessary to understand the real memory aspects of the 
software which is present in the machine. The fotlowing map 
describes the real memory aspects of the softwares and where 
it is mapped during the deadstart orocesse To make this map 
complete would require overlaying it with segment and page 
boundaries. Rather than attempt to produce this overlaying 
effects suffice it to say that (by convention) the boundaries 
described In this map occur at even page boundaries. Whether 
or not the pages which constitute any given area in the nap 
are paged is a function of the attributes of the segment to. 
which the area belongs. : 

The real utility of this map is in showing the relationship 
of values which are supp!tied to the SES Virtual Environment 
Generator through the skeleton SYSXDIR file. This skeleton is 
dynamically edited when the NVELINK procedure Is invoked to 
produce the <tw>XLDR file. The SYSXDIR var lables are 
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underlined in the relationships described after the map. By 
using the reftationships givens it is possible to compute the 
relative starting ftocations of different areas within a NOS/VE 
dump, 

It should be noted that the relationships given here are 
expressed in decimal byte addresses» while the machine 
addresses are hexadecimal. To pursue hexadecimal addresses 
requires a copy of the tinkmap file. Specifically» the toad 
addresses for Monitor, System Cores Job Tempfiates etce are 
contained in the Virtual Environment Generator output which 
immediately follows the LINKER output. 
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NOS Extended Memory (ECS) 
<--- Maximum NOS Memory Address 


<--- Load Offset 
NOS/VE Page Table 


<~-- Virtual Load Address 
NOS/VE Monitor 


NOS Trap Handler 
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NOS/VE Task Services 


(System Core/Job Template) 


<--- NOS/VE Length 
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{Avallable Memory Pages} 


NOS Page Table and EI 
<--~ Highest Machine Address 
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200 OVESvIEW OF _ INTEGRATION PROCESS 


The Integration process begins with the transmittal of a 
software products the command language procedures required to 
build the products installation procedure documentations and 
baseline documentation from the software development 
organization. Subsequent to this transmittals, the Integration 
project is responsible for maintaining the program library» 
standardizing the installation proceduress maintaining the 
installation procedure documentations and opreparing the 
software release package for the Software Manufacturing and 
Distribution organization, In the interim time between the 
initial transmittal and the release of a software products the 
Integration project schedules periodic builds. The outputs 
from these builds are delivered to software development and 
test organizations and/or made part of the software release 
package. 


201 RELATED DOCUMENTS 


Document Title Distributor 

NOS/VE Procedures and Conventions SeWe Fewer 

NOS/VE Command Interface ERS DCS - ARH3609 
NOS/VE Program Interface ERS DCS = ARH3610 
SES User's Handbook DCS - ARH1333 
CYBER 180 System Interface Standard DCS = $2196 

Simutated NOS/VE Program Interfaces ERS DCS —- ARH3125 
VEGEN ERS DCS — ARH25S51 
VELINK ERS DCS - ARH2816 
CYBIL Language Specification DCS = ARH2298 
CYBER 180 CPU CI Assembler ERS DCS - ARH1693 
CYBER 180 Simutator ERS DCS = ARH1729 
SES Procedure Writers Guide DCS —- ARH2894 
CYBER 180 Object Code Utilities ERS DCS —- ARH2922 


Source Code Utility ERS DCS —- ARH3883 
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2e2 STANDARDS 


In order to facilitate the Installation process» certain 
standards will have to be set and adhered to by all members of 
the Operating System and Product Set. These standards will 
cover the following items: 


a) All program libraries will have the same formats this 
wit? be defined by (TBD). 


b) All output tapes wili conform to some predetermined 
format in terms of numbers of files and what each file 
wild contains. This will be defined by (TBO). 


c) The above formats are intended to faciiitate 
establishment of oproceaduralized installation decks. 
This Impties that some convenient naming conventions 
must be observed. These conventions will be defined 
by (TBD), 


203 CATALOG MANAGEMENT. POLICIES 


The Integration project builds two systems in parallel and 
manages two catalogs for each system. The primary system is 
the system that is between the beginning of the build cycle 
and the feature code cutoff. The secondary system is between 
the feature code cutoff and the end of the bulld cycle. 
Primary system files begin in the INT1 catalog and move to the 
INT2 catalog after the system has passed Confidence Testing. 
After a system has reached Its feature code cutoffs, a 
stabilized feature buitd is moved to the DEV1 catalogs the 
build from INT2 is moved to DEV2,s and this system is now 
considered the secondary system. Also at this times a new 
primary system is started in the INT1l catalog by adding its 
planned feature code to the previous primary system. When a 
bulld has completed its integration cycles the final build for 
that cycle Is moved to the REL1 catalogs It is at this time 
that a build is considered a candidate for transmittal to 
other facilities for further devetopment work, a final Build 
Content Report is distributed and whatever usage documentation 
that is available is distributed. 
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The following diagram illustrates the function of each 


catalog: 
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In generals procedures executing from aie given catalog 
access onty those files which have the same tIevel of 
verification associated with them. The INT1 and INT2 catalogs 
will access the most recent compilerss SES tooiss etc. while 
the DEV1 and ODEV2 cataiogs access a previouss more stable 
tevel of utilities. 

The REL1 catalog represents the "frozen" catalog for which 
changes are no longer being accepted (typically a snapshot of 
the ftast build cycie). This is generally the system that is 
being run in SVL closed shop and is retained for duplicating 
problems found there. The REL1 catalog will change no more 
frequentiy than once for each bylld cycle. The INT2 and DEV2 
catalogs contain the latest stable builds (i.e. the builds 
have passed Confidence Testing) for the primary and secondary 
systemss respectively, The INTL and DEV1 catalogss howevers 
are "working catalogs" for the debug of new system fixess new 
procedures, etc. The stability of these catafogs cannot be 
predicted. 


204 BUILD. PROCEDURE. DESCRIPTIONS 


In order to understand the procedure descriptions which 
follows something should be said as to the sequence in which 
these procedures are used to generate systems. The follonrtng 
is an attempt to accomplish this? 


204-1 INTRODUCTION 


The command language procedures corresponding to NOS/VE 
builds all reside in the INTls INT2,5 DEVl»s or DEV2 catalogs 
depending upon the desired tevel of verification the system 
has attained. It is assumed that the DEV1 Ilevel of 
verification Is the minimum tevel of system verification 
required by most userss therefore the DEV1 catalog is 
frequently referenced in the remainder of this saectione To 
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obtain a listing of the complete set of command § tanguage 
procedures provided in the Integration catalogs execute the 
following command language sequence? 


SESeLISTPROC BeSESPLIB UN=<Integration_Catalog> 


Before running the build procedures as batch jobs, a check 
must be made to insure that the user number under which the 
job witt run has sufficient validation limits for the job to 
execute, The minimum vatues for certain timits must be as 
follows? 


24378 

unlimited 

unlimited 

4096 

2008 (Cif simulator is to use LOM) 

unlimited (each library is built via batch job) 


Oo 
Ww 
oun ew 8 8 


The current values may be obtained with the LIMITS control. 
statement. If they are not targe enoughs have the operations 
staff change them. 


204.2 INVOKING THE PROCEDURES 


The procedures described below are documented as 
"SES .<Procedure_Name>d",. In actualitys to inyoke the 
procedures in this manner assumes that there is a file named 
*PROFILE® in the current catalog which names the Integration 
catalog to search for the procedure (via the *SEARCH®# 
directive). The alternative mechanism for invoking these 
procedures is to code the procedure call as? 
"SESs<Integration_Cataiog>.<Procedure_Name>d", Many of the 
procedures use the '"PRCUNAM' yatue for substitutable user 
namess meaning that the catalog in which the procedure is 
found is the catatog which is searched for files. This is as 
it should bes since each of the Integration catalogs contains 
a different version of the system. 


All of the procedures descrjbed in this document have 
™HELP® documentation associated with them, Use the 
SESs<Integration_Catalog>sHELP.<Procedure_Name> call to have 
procedure documentation printed at your terminal. 

Practically all of the procedures described iin this 
document are written to execute in "BATCH" as well as ltoceal 
mode. In order to provide a consistent result when these 


2=5 
ADVANCED SYSTEMS INTEGRATION PROCEDURES NOTEBOOK - Cycle 3 
2.0 OVERVIEW OF INTEGRATION PROCESS 
20402 INVOKING THE PROCEDURES 


TFL PREP eee PRE RE EERE PPE EP, P PREP REE ER SD 2 SD Ee LE EE. Tce dade ddd d a dadadedoadatedhodadedeaded 


procedures are runs it is necessary to save many of the 
generated files as permanent files. While some purists see 
this as “catalog pollution", we make all attempts to preserve 
oniy those files which are necessary for future reference or 
usag@e Whenever possibile ltocal file names generated by the 
procedure are given unique names so as not to conflict with 
any user files, In numerous instancess convenient "reserved" 
file names are used to enhance the configurability of these 
procedures. For examples all files accessed by the procedures 
are searched for first as local filess then as permanent files 
in the catalog in which the orocedure is executings then 
(optionally) in the catalog specified by the "AREA parameter 
values and finatly in the catalog in which the procedure was 
found, Thuss if the name of a tool accessed by the procedures 
is knowns several versions of this tool can be tried through 
iterative executions of the procedures without requiring 
procedure modification. To aid in the tsolation of tools 
accessed by the procedures a “common deck" type structure is 
included In the procedure libraries which names many of the 
tools to be accessed by the procedures. These structures 
exist as records on the procedure Jtibrary which are INCLUDEd 
into the relevant procedure files Inttiatly we have 
partitioned these toots into the records !TOOLALL', 'TOOL170%»s 
and 'TOOL180". Experience has shown this partititioning to be 
somewhat combersome for some of the procedures» and will 
probably be fine-tuned in subsequent revisions of the 
procedure ltibrary. 

Some of the procedures contained on the procedure libraries 
change very frequently due to changes in system structure or 
for other reasons. It is inevitable that errors creep into 
the procedures at times. Often it is quicker to change the 
CCL generated as a result of invoking the SES procedure than 
to change the procedure librarye The SES processor may be 
invoked via the SES»TEST.<Procedure Name> mechanism and the 
resultant CCL is written to a file named SESTEST. This 
SESTEST file may then be editeds and the offending control 
statement corrected. <A subsequent CALL»sSESTEST statement may 
then be used to execute the corrected CCL. White we do not 
necessarily condone this approach to fixing procedure files we 
can hardly deny its existence. If» for examoles it should 
prove necessary to provide our customers with installation 
procedures for software which we generate with SES procedures» 
it would be our intent to ship the SES generated CCL 
statements rather than the SES orocedure and a copy of the SES 
processofes 
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20403 CURRENT PACKAGING OF NOS/VE SOURCE 


There are two execution modes of NOS/VE which are referred 
to as the “standalone” mode and the "“dual-state”™ mode. All of 
the NOS/VE source modules which execute in the CY180 Virtual 
State are contained on a program tibrary named 'NOSVEPL!. The 
program interfaces to the Virtual State systems those 
described in the NOS/VE Program Interface ERS, exist as common 
decks on a program library named "OSLPI*. The content of 
these two program libraries is referred to as the standalone 
System. A deadstart tape can be produced of the standalione 
system for execution on the hardware», or the output of the 
Virtual Environment generator can be executed directiy on the 
Hardware System Simulator. The [70 support of this standalone 
system when running on the simulator is defined in a separate 
set of common decks on a program tibrary named '‘'CYBICMN!, 
Refer to the SIimutated I70 ERS for documentation of these 1/0 
interfaces. 

The dual-state execution of NOS/VE»s in conjunction with the 
NOS operating system, requires NOS system modifications and 
the presence of a set of NOS utilities and procedure files, 
The software which supports this dual-state environment 3 from 
the 'NOS* side of the hardware is contained on a progrem 
library named *VE170PL%. Included in this package of NOS/VE 
support programs is a software application catled the Remote 
Host Facility which supplies Job-to-job communication between 
the Virtual State and NOS portions of the CY180 machine. 


20%e4 UPDATE THE SOURCE LIBRARIES 


The Integration project typically updates the base source 
libraries prior to starting any recompilation or assembly of 
the system, In order For a user of these procedures to modify 
the source of a system routine he/she can use the SES 
"GETMODS*® procedure to extract the source being modifieds or 
create the source in some other manners If GETMODS was used 
to extract the sources then REPMODDS can be used to put this 
changed source on a MADIFY program Jibrary In the user's 
catalog. Then the filename containing this program IJibrary 
must be specified as the value of the 'tAB* parameter of the 
NVEBILD procedure. (Refer to the Source Maintenance Section 
of the SES User's Handbook if you have questions about source 
maintenance.) 
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204.5 COMPILE/ASSEMBLE FROM SOURCE 


The efficiency of the Integration build procedures is a 
function of how much of the system Is being bullt and how much 
information its supplied to the procedures when they are 
invoked. If the name of each module to be recomplited and its 
object file residency Is known prior to itnvoking the 
procedures»s then the most efficient method is to use the 
NVEBILO procedure and specify the lists of module names and 
jibrary names via the *M!' and 'L* parameters. If onty the 
module names are knowns then the NVEBILD procedure with the 
*mM* parameter specified shouvitd be used (a search for the 
library names will be used). If onty a modset file is 
avaifabites the scope of changes Is not readily apparent (lee. 
several common decks are changed) or the number of modules to 
be recompiled is prohibitively targe for manual specification 
to the NVEBILD procedures, then the NVEBLD procedure can to 
used to automatically generate the correct NVEBILD procedure 
calls (using a NOSVEPL cross reference). If it has been 
determined ahead of time that several modules on the same 
library are being changeds then ft Is more efficient to 
rebuild the entire Jtibrary using the 'L* parameter of the 
NVEBILD procedure, If severat tibraries need to be rebuilt 
{as in a full system build)s then the NVEBILF procedure should 
be used. 

The general philosopy behind the NVEBILD procedure is to 
extract the tatest source of a module from a program Iibrarys 
compile or assemble the source to oroduce the appropriate 
object texts reptace/add the updated object text to the 
appropriate system tibrarys and save this tibrary in the 
catatog in which the procedure is executede The final result 
of the execution of the NVEBILD procedure should be an updated 
system tfibrary in the current user's catalog which is ready 
for the ®"LINKER*® phase of the build. Jobs which run in “user 
mode"» that Is the interface to the system is gnly through use 
of the program interfaces (OSLPI)» are saved merely as object 
text files in the user's catalog and LINKER=LOADER directive 
modifications are required to Include these files as part of 
the system. This ftatter capabitity will gradually be replaced 
by the Virtual State LOADER and Library Generator features as 
they become avallable. 
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2e%.6 BEGIN THE LINKER-LOADER PHASE 


The LINKER (SES53A6) and LOADER (SES53A5) are packaged 
together in the Integration procedure NVELINK. This is for 
convenience purposes» in that most LINKER changes to the 
system require a corresponding LOADER directive changes, and 
the intermediate results from the LINKER execution are not the 
primary output used for system checkout. Prior to starting 
the LINKER=LOADER phase of system builds, some decisions need 
to be made as to the target execution environment for the 
resultant output. 

If the target execution environment is standalone NOS/VE>» 
then the "LWeSIM* parameter to NVELINK should be used to 
Produce the file named *#SIMXX!'. This file can be run on the 
simulator using the NVESIM procedures or can be used to create 
a deadstart tape using the 'VSN*® parameter of the NVESYS 
procedures ji 

If the target execution environment is a dual-state 
environments then the 4#LW=SYS* parameter must be used 
firststhen "LW=J0B'. The *SYSXXsJOBXXYY® file is used by the 
NVESYS procudure to produce a deadstart tape image on disk 
named *TPXXXK*, which the dual-state deadstart procedure NVE 
will then = find. Refer to Appendix OD for Duat-State and 
standatone deadstart procedures. 


204-7 GENERATE THE DEADSTART FILE 


In order to generate a deadstart tape for standalone 
NOS/VE»s it is onty necessary to run the NVESYS procedure = and 
specify the VSN of the tape to be written, Prior to 
generating a dual-state deadstart files, howevers it is 
necessary to verify that the utilities necessary to support 
the dualestate deadstart have been rebuilt via the DSBILD and 
BLDEI orocedures. There are two portions of the dual-state 
EI$ the A170 portion is built using the BLDEI procedures and 
the C€180 portion (the NOS Trap Handter) is rebuilt using the 
NVEBILD procedure (deck named OSANTH), 


205 NVEBILO PROCEDURE DESCRIPTION 


The procedure NVEBILD is used to add or replace modules on 
a hbase object text file. NVEBILD retrieves the source module 
fron a program Jlibrarys using the following search order: 
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1) an alternate base optionally specified by the 
user (looking first in the current catalogs and 
then in the <Integration>d catalog) 

2) OSLPI (from the <Integration> catalog) 

3) NOSVEPL (from the <Integration> catalog) 


This module is then compiled or assembled, and the 
resuiting object text is either added to or replaced on a base 
file. A new version of the base file will be created in the 
current catalogs if "FULL"® keyword is specified If #FUII® is 
not specified, these procedures will create (lor update 
existing) library file{s) in the current catalogs the 
resulting contents begin only the modules which were just 
compited (added to any previousty modifyed binaries). The 
names of the tJtibrary fite(s) will be the same as the 
destination integration Jlibrary(s) for the modified modules to 
enable them to be merged with the integration binaries during 
the linking phase, This applies to selected module 
compliation only ('m! option). If the "LISTING! parameter is 
specified a direct access fila NOSLIST which contains the 
compifiation or assembly listing(s) of the modyle(s) compiled 
or assembted lone listing per records headed by the matching 
MADIFY module names will be created, If you specified 
"listing = tape vsnt then the listing will be archived to the 
tape. THis listing can be tisted via the LISTNVE procedure 
described in this document). If there are any compilaticn 
errorss the error tisting(s) will be out on the direct access 
file ERRORS (which has the same format as NOSLIST) in the 
current cataloge The direct access fille ERRLIST will contain 
a one tine error message which indicates the type of error 
detected for aii errors diagnosed by the procedures. By 
fisting the ERRLIST file from a terninals a summary of the 
number and types of errors encountered can be determined. 
There are conditions such as unrecoverable disk errors which 
can cause erroneous messages to occur in this file. In such 
case it is necessary to examine the DAYFILE produced by the 
procedure to ftsolate the problem. 


If a specified modute is to be replaced (ie. it is 
already part of the existing system)» NVEBILD will by default 
use the same compilation options and will replace it on the 
same base object text file as when it was first added to the 
system. These options may be overridden by specifying the 
corresponding parameters described below. 


If a specified module is new to the systems the compilation 
and base object text file options may be directly specified 
using the parameters described bertow.e If a list of new 
modules is specifieds the compilation and base file options 
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must also be specified as fists» and NVEBILD will match 
everything up positionally. If these parameters are oot 
specifieds and NVEBILD is executing in LOCAL modes a warning 
message will be issued teiling the user that the module ts not 
in the current system, The user will then be prompted for the 
necessary information. If these parameters are not specified 
and NVEBILD is executing in BATCH modes the compilation and 
base file options default as specified below. 


If the "#1 parameter is specified » each module's object 
text will be copied to a temporary '2' file. The ofd Jibrary 
file will then be purgeds and the 'z! fite will be renamed as 
the new tJtibrary file. All compilation tistings will be 
LIBEDIT*ed onto NOSLIST from a temporary listing file at the 
end of the procedure, 


When an entire tibrary is being rebuilt via the ‘ff? 
parameters the module names and their corresponding 
compjfation options are obtained from a file which contains 
ail this information for each tibrary. NVEB8ILD searches for 
this file first in the current catalogs, and then in the 
<Integration> cataloge The name of this file must be the name 
of the library minus its first character (e.g. "1432308 for 
the library "XLJ23D')» and the first line of this file must be 
the file namee To make additional entries or change existing 
entries in this files the following procedure should be 
followed: 


1) EXTRACT,<libdeks>/UN=<Integration>. 
(where <jibdeks> is the name of the compilation 
information file for the library as described abovey and 
<Integration> is the Integration catalog) 
2) Edit <tibdeks> to add or change entries. The format and 
spacing of each entry is important and must be as follows: 
(Cm 9<ore<xrefd>s<i1>s<t2>) 
where 
m = a 7V<character left-justifiled module name 
c = a l-character compilation option (fO%sti%s or #343 
see description of 'c! parameter below) 
xref = a 3~character feft-justified cross reference 
option (either "YES*® or "NO &) 
11 =» a Y—character tleft-justified destination library 
name, 
12 = a V-character tleft-justified secondary library 
destination name. 
the entries currently in these files all follow this 
format so that any additional entries may be tinned up 
quite easily with them. 
3) SAVEs<tlibdeks>,. 
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NVEBILD (with the "1 parameter specified) may then be used to 
rebuild the library using these new/modified compitation 
options. 


The format of the NVEBILD is as follows’ 


SES.NVEBILD € m=(<module name>..<module name>) ]j 

{f t2< tibrary name > Jj 

{ c=(<compl tation optiond. <compilation optiond) J] 
{ area = <€ user name D ] 

€ xrefz(< xref option>.».<xref option>) ] 
{C tisting= keyword or keyword=<tape vsn>] 
{C full keyword J 

{[ ab * <alternate base> ] 

C omit = (<Cmodule name>d..<module name>) ] 
{C tink = <parameter string for NVELINKD ] 
{ test = <parameter string for NVESIM> } 
{C print ] 

{ batch ] 


m t The module names or range of moduless or list of 
module names. 


! 3 The library name(s) onto which a newly compitfed 
module (or modules?) is (are) to be added or 
replaced. If the "4% oparameter has not been 
specifieds then the entire tibrary is recomoited. 
To recompite several libraries at a time It Is 
recommended that the NVESILF procedure be used. 


c 3 c = 0 to assembie a module 
c = 1 to compile a CYBIL module (DEFAULT) 
c = 3 to compile a CY8IL module using CYBICMN type 
deciarations 


area 3 Option to obtain the object files or Ilinker 
Parameter files from another user's catalog (other 
than the current catalog in which the procedure is 
executing). The default is for no area user 
catalog to be searched. 


fo 3 List options to be in force during CYBIL 

Compjiations. May be any combination of A» Cy» F» 
Os Is Ws Re or O (zero). The default Is 6 
(zero). 


ab 3 The user's alternate base program tibrary 
containing new and nodified modules. The default 
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is *NEWDKPL!, 


omit 3 Used when running 3 Full builds a module name or 
fist of module names to omit from the build. The 
default is none. 


fisting : For producing compilation listing as a permanent 
file or archive the listing to the tape, 
The default is not to save the listing. 


full 3: To add or replace modified modules into object 
libraries. The default is onty put modified 
modyule(s) into object tibrary. 


link 3: String passed as the NVELINK parameter TJists to 
optionally invoke the linker after compiling. The 
default is to not link the system. 


test : String passed as the NVESIM parameter tists to 
optionaliy invoke the simutator after linking. 
This parameter is invalid if the "LINK*® option has 
not also been specified, The default is to not 
run the simulator test. 


print 2 Nption to print the link map following the tinking 
of the system. The default Its not to print the 
link MaDe 


batch ?: Run NVEBILD in BATCH mode. The default is to run 
. it locallye 


NOIE : One of *m!? or "1! parameters must be specified. 


2e5e1 NVEBILF PROCEDURE DESCRIPTION 


NVEBILF is an SES procedure file which submits one batch 
procedure execution of NVEBILD for each system tibrarys, each 
with the '!* parameter specified for the tibrary to be bulilte 


The format of the NVEBILF is as follows: 


SES eNVEBILE C It = <library name >] 
{ batch ] 
{ tisting = <tape vsnd>] 


1 3 The "{* parameter specifies the library to be 
bull t. It can be one SJibrary or a list of 
libraries. The default is to rebuild the entire 
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system. 
fisting? To archive the listing to the tape. The default 


is not to archive the listing to the tape. 


“batch 3 Run NVEBILF in BATCH modee The default is to 
run it focally. 


Note : To rebuild one library, the following are togically 
equivalent: 
1) SESeNVEBILF t=< Jibrary name > 
2) SESeNVEBILD t%2< fibrary name > batch 
The expansion of either of the above procedures can be 
prohibitively tong when being run from ai terminal. The 
'bhatch' keyword on the NVEBILD orocedure is implemented for 
the express purpose of freeing up the terminal for other 
purposes (the procedure expansion is done within the BATCHed 
job). 


205-2 NVEBLD PROCEDURE DESCRIPTION 


The NVEBSLD procedure generates and routes to the Input 
queue a set of NVEBILD jobs which compite the nodified or 
replaced decks and those decks which call modified or replaced 
common decksSe Firsts, NVEBLD finds the decks modified by 
creating a tist of all the *DECK tines In the "mf! file(s) and 
a fist of allt’ the decks in the 'dkf* fijie(s). It combines the 
two Listss sorting and deleting duplicate names. The combined 
fist is checked against the current tist of modules which make 
up NOS/VE»s using the cross reference file from the ‘'‘xrf! 
parameter. Then the procedure again creates two lists: a tist 
of nodules to be compiled and a list of common decks to be 
checked. A subset of the cross reference is used to generate 
a list of atl decks referencing the given common decks, The 
fist of modules and the list of decks referencing the modified 
common decks are combineds sorted and duplicates are removed. 
This final tist is then used to generate the NVEBILD jobs to 
compile the necessary modules. 

The format of the NVEBLD Is as follows: 

SES.NVEBLD C mf = <file name> ] 
{C dkf = <file name> ]j 
{ xrf = <file name> ] 
C ni = <ilobrary_name>d } 
{ area #* user name> ] 
{ ab = <file name> ] 
Clisting = <tape vsn>] 
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Cfull = keyword ] 
{ batch $ local ! defer ! batchn ] 


mf 3% The file or tlist of files which contains the 
modsets or a list of *DECK deck names, If the 
Parameter Is omitted the file MODFILE Is used. 


adkf 3: The file or dist of files which contains the new 
or replacement decks in a group file format. If 
the parameter is omitted the file DECKFIL Is 
used. 


xref 3 The NOS file name for the fite containing the 
cross reference of NOSVEPL. If the parameter is 
omitted the file XNVEPL is used. 


ni 3 The list of tibrary names to be omitted from the 
bujld. There Is no default. 


area 3 The search order to find any fite. If the 
parameter is omitted the user names of the current 
user and the user name of the procedure are used 
for the default user names. 


ab 3 The file name of the alternate base. The default 
is NEWDKPL. 


fisting : To archive the fisting file to the tape. The 
default is no listing tis archived. 


full 3 To add or replace modified module(s) into object 
libraries. 


batch ! focal 3 defer {$ batchn : The job run mode of the 
procedure. If none are defined LOCAL is used.e 


20523 LISTNVE PROCEDURE DESCRIPTION 


LISTNVE ts an SES procedure fila which extracts the 
compitation tistings of the modules specified by the «mM! 
parameter (module names correspond to the MADIFY deck name 
given the module) from a text library file and writes them to 
the file specified by the 01 parameter in a printable 
formate The *M* parameter may select a singte modules a tist 
of modules, and/or a range of modules on the tibrary file. 


The tibrary file which contains the tistings may be 
selected via the ‘'I* parameters and defaults to NOSLIST. 
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LISTNVE will search for this file in the current catalog 
firsts, and If it is not there it will go to the catalog 
specified by the "AREA! parameter. 


When LISTNVE has completed, the output file selected by the 
*O* parameter will be a local fille. [t is not automatically 
printed untess either the 'PRINT® ofr BATCH? option is 
selected, 


The format of the LISTNVE is as follows: 


m2 { <module name>.»<module name> ) 1] 
i = ¢file name> ]j 

vsn = <tape vsn> j 

o = <print file name> j 

area = <user name> j 

print ] 

fiche = <tape vsn> ] 

batch 1] 


SES»LISTNVE 


rene re emo 


m 2 The modute name(s) and / of range of module 
names which are to be extracted (for 
printing. The default is to extract and 
format all of the modulese 


it f 3 from 3 The name of the text Jibrary file from 
Which the comptlaticon tistings are to be 
extracted. 


vsn 3 Tape vsne For archiving the tisting file 
to the tape. The default is NOSLIST. 


0: to { upon : The name of the file which will receive the 
formatted listings to be printed. The 
default is LISTINGS. 


are@a 3 The name of the catalog to search for the 
fibrary file should it not be found in the 
current catalog. The default is the 
<Integration> catalog. 


print 3 Option to print the listing file after it 
is formatted. The default is to not print 
the listing file, 


fiche 3 Write tlisting output to the tape with this 
VSN in a format suitable for microfiching. 
The default is to not microfiche the 
listing. 
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batch ! Run LISTNVE In BATCH mode. The default is 
to run it locally. 


226 NVELINK PROCEDURE DESCRIPTION 


NVELINK is an SES command fanguage procedure file which 
will call both the VE Linker and VE Generator (supptied by the 
Development project) to produce various optional image files 
and tink map files. In order to do this it wil! link monitor 
and task service routines from thelr object text files. It 
will) search all files that it requires 1) from ftocal files 2) 
from the current catalogs 3) from area user's catalog (if the 
area parameter is specified)» 4) from the <Integration> 
catalog. 


Tt is no fonger necessary to keep conplete object libraries 
in the current/area catalogs when modifications have only been 
made to a few modules. Insteads the changed modules should 
reside on (an) object file(s)» with the same name(s) as their 
destination object library s)>» in the ‘current/area 
catatog(s). NVELINK then applies these modifications on top 
of the current <Integration> Jibrariess applying first the 
area catalog changes (if any) and then the current catalog 
changes (this function is oerformed by the SES GOF utility 
entirely on focal files; at procedure end the libraries 
residing in the current/area catalogs remain exactly as they 
were before NVELINK was. Invoked). This made necessary an 
option to dynamically delete modules no tftonger needed on a 
jibrary. This is done via the *p! parameters which specifies 
a file containing the name(s) of the module(s) to delete and 
the ftibrary(s) to delete it (them) from. This file must be in 
the format ifflustrated by the following example: 


F2(XLS130)5sMODULE=(PMMSPROGRAM_SERVICES» 
JMMSPROGRAM_LEVEL_L INTERFACES sPMMSSYSTEM_ TIME REQUESTS» 
MLM$HANDLE_ SIGNAL) 

Fe(Xl$10D)»5MODULE=(OSMS$INTRINSICS) 

Fe#(XLJ223) sMODULE=( AVMS INITIALIZE »sAVM$ JOB_ ACCOUNTING _KERNEL>» 
AVMS JOB_LIMITS. MANAGERsCLMSREAD_LINPUT_LFILE) 

@tCeee 


Note! Each new entry (flagged by "F=") must begin in column 
one of a new line. Alsoseach tibrary file name and tist of 
modules gust be enclosed in parantheses. 


NVELINK will link any one of the following? the Production 
System Core and/or the Recovery System Cores or the Production 
Job Template and/or the Recovery Job Template. The choice is 
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made via the ‘LW* and *f#REC! parameters (see descripticn 
below). The folftowing table indicates what output files are 
saved in the current catalog after NVELINK has completeds and 
what their various names are devending upon the 'LWt and !REC! 
options? 


+; LW2J0B ; LweSy¥5S + LWeJOB REC ¢ LWaeSYS REC 


checkpoint? PJB<cid><jid>i PSY<cid> IRJR<cid><Jid>! RSY<cid> 
file ; ; H H 


linkmap § PMP<cid><jid>d! PMP<cid> IRNP<cid><jid>! RMP<cid> 
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outboard } | H ; ; 

symbol + PJBST<cid> tPMTST<cid>s RJIBST<cid> $ RMTST<cid> 
tables H IPSYST<cid>! § RSYST<ci d> 
cadet H H H H 
directives: JOBXLDR + PSYXLDR 3} JOBXLDR ; RSYXLOR 
file H ; H H 

linker H ; ; H 

debug + PJBXDSG + PMTXDBG : RJIBKXDBG + RMTXDBG 
table : + PSYXDBG 3} ; hleaanae 


where <cid> = Value given the CID parameters and 
<jid> = Value given the JID parameter. 


To fink additional user Jobs into the systems create a file 
in the current catalog containing the commands needed to 
obtain afl the necessary files as well as a call to VELINK for 
each user Job to be tinked, Specify this flie via the aA0DO0 
parameters and NVELINK will pick it up and physically insert 
it into procedure command stream immediately following the 
fast caf! to VELINK. [he first line _in_this. file MUST _be the 
file_naneii_ 


The format of the NVELINK ts as folfows? 
SES SNVELINK € tw = € link option > 1 

{C rec J 

{ cid = ¢€ core Id > ] 

{ jid = ¢ job id > ] 

{[ ps = < page size> ] . 

{C pti = <¢ page table fength > ] 

{ d = < DEOQM directives file name > Jj 
C add = <¢ additional tinks file > J] 

{ uj = < ftist of object files > Jj 
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C nvesim = ¢€ parameter string for NVESIM > Jj 
{C nvesys = < parameter string for NVESYS > Jj 
€ dumpsnodumo Jj 
C area = < user name > ] 
{ debug ] 
{ print = < tink option > Jj 
{ batch ] 
iw t The tink options used to determine which 
"pieces" or variations of the system are to be 
linked. 


LW = JOB tinks onty the system job template 
(DEFAULT). 
LW = SYS tinks only the system core. 


rec 2 Option to Jink goth the Production and Recovery 
System Cores/Job Templates (depending on the 
*LW' selection). The default is to tink only 
the Production System Core/Job Template. 


cid 3 Two character string which becomes the system 
core identifier and is appended to the names of 
the NVELINK output files to identify the system 
core version which was just tinked or which is 
to be used in the current tink of a $job 
tempiate, The default is *Xx*. 


jid Two character string which becomes the job 
temptate identifier and is appended to the names 
of the NVELINK output files to identify the job 
template version Just linked. The default is 
fyy?, 


ps 3 Page size of the target NOS/VE systems expressed 
in multiples of 10924 bytes. Values may be ls 2» 
4» 85 16s 32,5 or 54. Default is 8. 


pti 2 Page table tength of target NOS/VE systems 
expressed in multiples of 1024 bytese Values 
may be 4» 8s 18s 32,39 64, 128s 256) 5125 or 
1024. Default is 32. 


d 3 The name of the file containing the information 
necessary to delete modules from tibraries 
before ftinking. The format of this file is 
described above. The default is to not delete 
any object modules bsafore tinking. 


add 3 The name of the File containing the commands 
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needed to link additional user jobs Into the 
system. The default is to not tlink in any 
additional user jobs. 


uj : (List of) object file(s) containing user 
programs which are to be linked into the system 
ajiong with the library XLJBBB. 


nvesin String passed as the NVESIM parameter tists, to 
optionally invoke the simulator after linking. 


nvesys 3 String passed as the NVESYS parameter tists to 
optionally build a daadstart file or stand-alone 
deadstart tape after linking. 


dump/nodump Option to print a memory dump of the system. 
The default is '*NnoqDUMP?, 


area 3 Option to obtain the object files or tinker 
parameter files from another user's catalog 
(other than the current catalog in which the 
procedure Is executing). The default is for no 
area user catalog to be searched. 


debug 3 Option to save the linker output debug tables as 
permanent files In the current cataloge The 
names of these filess when saveds are given iin 
the table above, The default is to pot save 
these files 


print 3 The print option, used to determine which 
finkmaps to print. The default is not to print 
the ftinkmap. If only the print keyword Is 
specifieds the finkmap(s) matching the ‘ftw? 
option selected is printed. 


batch 3 Run NVELINK In BATCH modee The default is toe 
run it tocally. 


20601 LPF FILE DESCRIPTION 


The LINK commands used in the NVELINK procedure do not 
specify enough information to totally define the requirements 
of the linking operation. Many additional parameters are 
supplied to the tinker through additional data files. This 
includes information such as? 
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-~ Ring Numbers 

- Segment Numbers 

- Segment Attributes 
- Execution Privilege 


Currently this information is supplied to the finker via 
the SES Linker Parameter File (LPF) file. The linkage between 
the tj] nker and the L PF file is activated by the 
LPFe<file name> parameter on the LINK commands. For the 
monitor ftinkage this information is on LPF file MTRXLCB,s 
system core/job template linkage information is on LPF files 
SYSXLCB and JOBXLCBs, the xXLJB8BB (and other optional user 
object files) finkage information is on LPF file BBBXLC3,s and 
EI tinkage information Is on ETLC8. 


20602 SYSXDIR # LOR FILE DESCRIPTION 


The SYSXDIR file used by the procedure NVELINK contains 
directives to the CPF Generator which allow It to produce a 
checkpoint file from the segment files produced by the VE 
Linker. These directives set uo the physical environment into 
which NOS/VE is placeds and include such things as the 
definition of the page sizes job and monitor exchange package 
addressess page table address and tengths preallocated segment 
array definitionss etc. 


SYSXDIR ts a "skeleton" File which is dynamically edited 
during the execution of the NVELINK orocedures depending upon 
the specification of the LWs PS» RECs and PTL parameters. The 
edited file is then put on an indirect access files named 
according to the conventions outlined in the NVELINK Procedure 
Descrintioan sections in the user's catalog. It contains the 
directives to the CPF Generator which set up the physical 
environment for that particular link. This file must remain 
permanent in the user's catalog after NVELINK has. been 
executeds as the procedure NVESYS uses this file in building a 
deadstart tape. 


207 PARAMETER DESCRIPTOR TABLE_ AND MES SAGE_TEMPLATE BUILDING 


Z2e7ol GENPDT AND BLDGPDT DESCRIPTIONS 


An SCL Parameter Descriptor Table (PDT) is ae sufficientty 
complicated "type" that its deciaratonys in particular its 
initializations in CYBIL Is awkward. Therefore, a means of 
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easily generating a POT has been devised, 


GENPDOT is an SES procedure which provides for the 
generation of a PDT from a specification that is virtually 
identical to an SCL proc declaration (see the NOS/VE Command 
Interface ERS» ARH3609). 


The output of GENPDT is a file containing the CYBIL 


wariable dectarations for the PDT specified. AS a general 
rule this file should be formatted using the CYBIL source code 
formatter. 


The format of the GENPDOT is as follows: 
SES -GENPDT { i = <file named) 
{ o = <file name>] 


i: The name of one file containing one POT 
declaration. Biank Jines and continued tines 
are allowed. The default is INPUT. 


0 2: The name of the outout file. Ali lines from #i't 
are echoed on this file in the form of "block" 
comments. 


See the ERS for Parameter Descriptor Table Generator for 
the POT declaration format and examples (GPDTERS/UN=SCL). 


The SES procedure BLDOGPDT buitds the generate parameter 
descriptor table program that is used by GENPDT. 


The format of the BLDGPDT Is: 


SES-BLDGPDT € t = <file nameD ] 
{C b = <file name> ] 


} 3 The name of the file which wit! receive the 
listing. The default is LISTING. 


b3 The name of the file which will receive the 
binaries. The default is GPDOTBIN. 


2e7Te2 GENMTs GNVEMT AND BLDGMT DESCRIPTIONS 


GENMT tis an S€S procedure which takes as input 1 or more 
CYBIL common decks containing Exception Condition Code 
definitions with status severity and message temptate 
specified in an accompanying CYBIL comment and oroduces 2 
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ready-to-compile CYBIL module which consists of CYB IL 
variables that represent the message temp!tates. The commen 
decks that are used as Input should be stripped of the MODIFY 
headers andthe line COMMON. The CYBIL module produced would 
next be compiled and included with other object files so the 
message formatter can locate the nessage template. 


The format of the GENMT is? 


SES «GENMT C i = <file name> ] 
{C id = <2-character identifier> ] 
{C 0 = <file named ] 
{ e = <file name> ] 


i: f 3 The name of the file containing common decks to 
be used as input. The default is INPUT. 


id 3 A two-character product identifier. The default 
ts OS. 


o 3 The name of the file to contain the CYBIL module 
which is output. The default is TEMPLAT. 


e 3 The name of the file to be used for error 
fisting output. The default is DUTPUT. 


The SES procedure BLDGMT builds the g@nerate message 
templates programs generates the message templates for the 
operating systems and produces the message template object 
module and puts it in object library XLJ2DD-. 


The format of the BLDGMT is as follows: 


SES -BLOGMT { 1 = <file name> J] 
{ b = <file name> ] 


! 3 The name of the file to receive the tisting. 
The default is LISTING. 


b 3 The name of the file to receive the binaries. 
The default is GMTBIN. 


The SES procedure GNVEMT produces the message template 
object module for the operating system and puts it in the 
object libary xiJ200. (It Is INCLUDEd by BLDGMT and it 
INCLUDES GENMT.) 


The format of the GNVEMT is as follows: 
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SES.~GNVEMT € bl = <file name> ] 
{C e » <file name> ] 


bl 3 The name of the fite to receive the object 


modufe. The default is MTLGO. 


e 3 The name of the output file. The default 


OUTPUT. 


268 NOSZVE_SIMULATION 


2081 RUNNING A SIMULATOR TEST (NVESIM PROCEDURE) 


NVESIM is an SES procedure file which will run either 
This 


batch node or an interactive simulation of NOS/VE. 

option is selected via the "TEST! parameter. If "#TEST? is 
specifieds, then the simulation will be run interactively. 
a batch mode simulation is desireds then f#TEST? is used 


is 


a 


not 
If 
to 


specify the name of the file containing the NOS/VE test 
commands that are to be input to the simulator. The 't#BATCH? 


keyword must also then be specified. If the user wants to 


use 


his/her own simulator directives fila, the 'CMDS* parameter 


must be specified. | 


NVESIM atso allows the selection of the checkpoint file to 


be used for the start of simulation, A checkpoint file 


may 


also be optionally saved at the end of the teste. The C189 


memory size may be changed via the *MEM! parameter, 


The NVESIM procedure will create several permanent files 


in 


the user's catalog If not run IiInteractively. These are 


itemized as follows: 


1) [QUIPUIT. This direct access File contains all of 

output of the NVESIM procedures inctuding 

- a copy of the command file used as input to 
simulator ('TEST* parameter) 

- the output produced by the system 

- the SESLOG file 

- a reformatted keypoint listing 

- DEBUG output Cif "SIMDBS* was specified on 
NVESIM call) 

- a summary of all (paging) disk I/0 (HIGLOG file) 

- the foad map produced by the CITOII conversion 
execution of XUUTL (SIMLOAD file) 

- f{optionally) a hex dump of the checkpoint file 


the 


the 


the 


and 


at 
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the end of simulation 
- the job dayfile. 
This file is automaticattly sent to the tine orinter. 


2) SESSMKE. This direct access file contains the keypoint 
data produced by the simulator. It is reformatted by 
the procedure NVEKEY before being written to the file 
TOUT PUT. 


3) [CLDQAYE. The dayfiie of the NVESIM job will be written 
to this direct access file should it terminate 
abnormally. 


Addittonallys if the ‘'"NCPF* parameter is specifieds NVESIM 
will create 2 direct access files which together contain the 
NOS/VE environment at the end of simulatione The file 
specified by the "NCPF® parameter wlll contain the current 
NOS/VE checkpoint file. The other file (formed by adding the 
character *60* to the 'NCPF! file name - which must therefore 
be six or less characters tong) is used for NOS/VE memory 
paging. 


The format of the NVESIM is as follows: 


SESeNVESIM C test = < command file > J] 

{ emds = < simulator directives file > ] 
{ cpf = <€ checkpoint file > J 

C nepf = < new checkpoint file > J] 
{ mem = < memory size In hex > ] 

{ nods ] 

{C run #® € instruction count D> ] 

{ simdbg ] 

C dump Jj 

{ area = < user name > ] 

{ batch ] 


test 3 The fille containing the NOS/VE test commands. 
The default is to run interactively. 


cmds 3? Simulator directives file which should be 
suppiied by the usere The default is to use the 
one created by the NVESIM procedure. 


cpf 2 The checkpoint file used “for the start of 
simulatione The default is "SIMXX"™,. 


nepf 3: The checkpoint file to be saved at the end of 
simulation, The default is not to save a 
checkpoint file. 
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mem 3% The C1860 machine memory sizes in hexs needed to 
run the simulation. The default is 
#590000(16)". 


nods 3 Option to use the version of the checkpoint file 
from the <Integration>d catatog which has already 
been deadstarted. The default is to use a 
Checkpoint File which has not been deadstarted, 


run 32 A count of the number of suimutfated instructions 
to execute. The default is 800000 Instructions 
(or the profile variabte vaiue for "RUNCNT'), 


simdbg 3: Option to turn DEBUG on for the current 
simulator run. The default Is to run with DEBUG 
off. 

dump ? Option to include the dump of the checkpoint 


file at the end of simulation as part of the 
NVESIM output, The default is not to dump the 
checkpoint file, 


area : The name of the catalog to search for the files 
needed to simulat2? the system shoyld they not be 
found in the current catalog. The default is 
the <Integration> catalog, 


batch 3 Run NVESIM in batch mode. The defauit is to run 
it locally. 


208.2 NVEKEY PROCEDURE DESCRIPTION 


NVEKEY is an SES procedure file which creates a simulator 
generated keypoint trace file. The output of this procedure 
is the focal file "KEYFILE?®. 


The format of the NVEKEY is as follows: 


SES-NVEKEY C€ kpf # <¢ keypoint file > Jj 
{C format = < SIM | HDW > J 
C kd = <€ list of keypoint descriptor files > J] 
{ area = < user name > j 


kpf 3 The keypoint file generated by the simulator 
which is used as Input to XXM7KEY. The default 
is *SESSMKF?, 


format 3 Specifies whether simulator or hardware format 
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area 


keypoints are being processed. Default is 
'SIM?. 
A fite or fist of files which define (s) the 


keypoint descriptions, The default is 
*KEYDESC?, 


The 


name of the catalog to search for the files 


needed to create the keypoint trace file should 


they 


not be found in the current catalog. The 


default is the <Integration> catalog. 


20823 DUMPING A SIMULATOR CHECKPOINT FILE (NVEDUMP PROCEDURE) 


NVEDUMP is an SES procedure file which makes a DSDI dump of 
a simulator checkooint file. 


The format of the NVEDUMP Is as follows? 


SES ,NVEDUMP 


cpf 3 


dump 3 


print 3 


area % 


epf = <€ checkpoint file > ] 


= € output file > J 


{ 
{ 
{C dump = STND ¢ ALL J 
{ print ] 

{[ area = < user name > ] 

{ batch ] 

The checkpoint file which is to be dumped. The 
default is "CKPT", 


The file which is to receive the dump output. 
This file wilt! be ae tocai file after the 


procedure has finished execution. It is aot 
automatically printed. The default is 
"OSDIOUT*,. 


Dption to either dump the environment according 
to ASID (DUMP =STND) or dump the entire 
environment (DUMP#ALL). If "OUMP2=STND" is 
chosens then the DSDI directives are taken from 
the file DSDIX»s which the procedure will search 
for first in the current catalog and then in the 
<Integration> catalog. The default is 
"DUMP#STND",. 


Option to print the ODSDI dump output. The 
default is not to print the dump. 


The name of the catalog to search for the files 
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needed to make the DSDI dump should they not be 
found in the current cataloge The default is 
the <Integration> catalog. . 


batch 3: Run NVEDUMP in RATCH mode. The default is to 
run it tocatly. 


209 BULLDING_A_DEADSTART EILE 
2091 INTRODUCTION 


229.2 CREATING THE FILE (NVESYS PROCEDURE) 
\ 


The SES procedure NVESYS builds a deadstart file from the 
image files created by the tinking of the system. The REC! 
Parameter ajlows the option of building either aéioProduction 
System or a Recovery System deadstart file. If the parameter 
"VSN? is specifieds then the deadstart file will be written to 
tape; otherwise it is written to the file TPXXXK. 


NVESYS requires additional object files for tInclustion on 
the deadstart file. These object files contain PP object code 
for the fotfowing functions: 


1) Deadstart (file XIOST) 

2) Console/Printer drivers (file XIDSP) 
3) PP helper (file XTHL?P) . 

4) PP Resident program (file XIRES) 


5) NOS/VE disk drivers supporting multipie. 
controllers (files XD4»s XD5As XD5Bs, XD5C» and 
XD5C2) 


6) NOS/VE MCU Driver (file XMSPMCU) 

7) System Monitor Unit (file XSMUPP) 

8) Monitor Display Oriver (file XmDD) 
9) System Monitor Assistant (file XSMA) 


A copy of the toader directives (file PSYXLDOR) will be 
Included on the NOS/VE deadstart file (a description of this 
file ts included in a previous section). <Atso inctuded on the 
deadstart file are the Production System Core Command Fite 
(DCFILE)s» the Recovery System Core Command Fite (RDCFILE) if 
*REC* is specifieds and the Configuration Prolog File 
(PROLOG). 
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If any of the above files are not praesent in the current 
user catalogs they will be obtained from the appropriate 
catalog, (ie. SES» INT2. prefixed procedure calls access 
INT2 fevel system files onty» white SESsINTI1. prefixed 
procedure calls may access files from either INT2 or INT] 
catalogs as Is appropriate for the system being built.) 

The format of the NVESYS is as follows? 

SES NVESYS C€ vsn = < tape vsn D ] 
{ cpf = < Production System Core image file > ] 
{C jtf = < Production Job Template image file > ] 
{C ropft = <¢ Recovery System Core image file > J 
{C rjttf = < Recovery Job Template image file > ] 
{C area = <€ user name > j 
{ enmds = ¢€ tape generator commands file > 1] 
{ pack Jj 
{ nocti ] 
{ rec ] 
{ batch J] 


vsn 3 The VSN of the tape to be written. This tape 
Must be available to the operator. The default 
is to write the file to a disk file as specified 
above. 


cpf 3 The Production System Core image “fite. The 
default is PSYXX. 


Jef 3 The Production Job Template image file. The 
defauit is PJBXXYY. 


reopf 3: The Recovery System Core image (file. The 
default Is RSYXX. 


rjtf : The Recovery Job Temptate image fite. The 
default is RJBXXYY. 


area 3 The name of the catalog to search for the files 
needed to buitd the deadstart tape or file 
should they not be found in the current 
cataloge The default ids the <Integr ation> 


catalog. 
cmds } The name of the file containing directives for 
use by the deadstart tape generator. The 


defauit is to use procedure-defined directives. 
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pack 3 Option to pack the deadstart file for dual 
state. The default is to nat pack the deadstart 
file. 

nocti ? Option to not put CTI on the deadstart file. 


The default is to write CTr to the beginning of 
the deadstart file. 


rec 2 Option to bulld a Recovery System deadstart 
file. The default is to build a non—Recovery 
System deadstart filee 


batch 3 Run NVESYS in BATCH mode. The default is to run 
it locaily. 


20903 COMPILING 180 PP CODE (CPP180 PROCEDURE) 


CPP180 is an SES procedure file which compites 180 PP 
code. The source for the PP code is retrieved from a source 
Program library. If the "AB™ parameter is specifieds CPP189 
will search this PL first before searching NOSVEPL to satisfy 
externals. NOSVEPL comes from the <Integration> catalog. 


The format of the CPP189 is as follows: 


SES.CPP180 £ m = < module name > J] 
{ ab = <€ aiternate base > J] 
{ area = < user name > ] 
{C listing = keyword or keyword =<tape vsn>] 


{ batch ] 

m 3 The modute name of the PP oprogram to be 
compiled. 

ab 3 The alternate base searched by CPP180 to satisfy 


externals before searching NOSVEPL. The default 
is to search onty NOSVEPL. 


fisting ? To save the compilation listing as a permanent 
file or archive it to a tape. The default is no 
fisting is saved. 


area 3 The name of the catalog to search for the PL 
specified by the "AB* parameter should it not te 
found in the current cataloge The default Is 
the <Integration> catalog. 


batch 3 Run CPP180 in BATCH mode. The default is to run 
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it focally. 


2210 DUAL_STATE PROCEDURES 


2010.1 BLDEIT PROCEDURE DESCRIPTION 


BLDEI Is an SES procedure file which builds the absolute 
File for dual state EI, The ASR oarameter may be specified if 
a program tibrary containing the dual state EI source exists 
in the current catalog; otherwise BLDEI retrieves EI from 
NOSVEPL In the <Integration> catalog. 


BLDEI uses the tinker parameter file EILCB to tink EI. If 
this file does not exist in the current catalogs it is 
obtained from the <Integration> catalog by the procedure. 


The outputs of BLDEI incjude the direct access absolute 
file "EI*® and the direct access file "*DSLIST® which contains 
the assembly listing and the tink map for EI. 


The format of the BLDEI is as follows? 


SES .BLDOET { i = ¢€ EI source File > ] 
{ area = < user name > J] 
{C listing = keyword or keywordz<tape vsn> 1] 
{ batch ] 


i: The file in the current catalog which contains 
the dual state EI source program Jibrary from 
which EI is to be built, The defauit is to get 
the EI source from NOSVEPL in the <Integr ation> 
catalog. 


fisting 3 Option to save the compilation tlisting in a 
permanent fife or to archive the listing to a 
tape. The default is no ftisting is created. 


ab 3 The user's aiternate base program library 
containing new and modified modules. 


area Option to obtain the object files or linker 
parameter files from another users catalog 
(other than the current catalog in which the 
procedure {s executing). 
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2¢19.2 BLDL70 PROCEDURE DESCRIPTION 


BLD170 is an SES procedure file which builds the A170 dual 
state deadstart tape binaries containing the modifications to 
A170 NOS to support dual state. The assembled binaries are 
put on the direct access file SYSBINS. The COMPASS assembiy 
listings may be saved either on disk (file OSLIST) or on tapes 
depending upon the specification of the tLISTING* parameter. 


The format of the BLD170 is as foltows; 


SESeB8LD0170 € m= < tist of module namesd Jj 


{ ab = < alternate base fille D> ] 
{ area = <€ user name D> Jj 
{ tisting 3 tisting = < tape vsn > Jj 
{C batch ] 
m 3 The module name(s) of the COMPASS routines to be 


assembled. The default is to assemble all of 
the A170 NOS dual state support modifications, 


ab 3 The user's alternate base program tibrary 
containing new and modified modules. The 
default is NEWDKPL. 


area 3 Optional catalog snecification to add to the 
search tist for files needed by 8LD179. The 
default is the current catalog. 


fisting 3 Specifying the keyword 'f#LISTING! saves the 
assembly listings on the direct access file 
DSLIST. Specifying 'LISTING=<tape vsn>! writes 
the assembly listings to the tape with the 
specified VSN in sorted order. The default is 
to not save any listings. 


batch 3 Run BLD17G6 in 83ATCH modee The default is to run 
it locally. 


201023 SLOICF? PROCEDURE DESCRIPTION 


BLDICF7 is an SES procedure file which builds the 170 
library file LINKLIB, This tibrary contains the binaries for 
the 170 side of the Interstate Communication Facility. The 
SYMPL/COMPASS tistings may be saved either on disk (file 
DSLIST) or on tapes depending unon the specification of the 
4LISTING® parameter. 
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The format of the BLDICF7 is as follows: 


SESs-BLDICF7 € m= < tist of module names> } 
{ ab = < alternate base file > J] 
{ area = < user nama > j 
{ tisting ! tisting = < tape vsn D> J 
{C batch ] 


m 3 The module name(s) of the routines to be 
assembled/compliled. The default is to assemble 
all of the modules which make up the LINKLIB® 


library. 
ab 3? The user's alternate base orogram tibrary 
containing ne@nw and modified modules. The 


default is NEWDKPL, 


area 2 Optional catalog soecification to add to the 
Search tist for Files needed by BLDICF?7. The 
default is the current catalog. 


fisting 3: Specifying the keyword ‘LISTING’ saves the 
assembly listings on the direct access file 
DSLIST. Specifying "LISTING=<tape vsn>?* writes 
the assembly tistings to the tape with the 
specified VSN in sorted order. The default is 
to not save any listings. 


batch 3 Run BLDICF7 In BATCH mode. The defayit is to 
run it tocally. 


201004 BLOIF7 PROCEDURE DESCRIPTION 


BLDIF7 is an SES procedure fite which builds the A170 
deadstart tape binaries needed to support the NOS/VE 
Interactive and Qperator Facilities. The tinked binary 
absolutes are put on the direct access file SYSBINS. The 
compilation/assembly tistings may be saved etther on disk 
(fite OSLIST) or on tapes depending upon the specification of 
the "LISTING® parameter. 

The format of the BLDIF7 is as follows’ 

SES -BLDOIF7 C ab = ¢€ alternate base file > J 
{ area = < user name > J 
{ debug ] 
{ tisting | listing = < tape vsn D ] 
{ batch ] 
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ab 3 The user's alternate base program library 
containing new and modified modules. The 
default is NEWDKPL. 


area ? Optional cataiog specification to add to the 
search tist for files needed by BLDIF7. The 
default Is the current catalog. 


debug : Deption to fink Interactive with NETIOD. The 
defauit is to link with NETIO. 


listing 3 Specifying the keyword ‘fLISTING* saves the 
assembly fistings on the direct access file 
DSLIST. Specifying "LISTING=<tape vsn>!? writes 
the assembly fistings to the tape with the 
specified VSN in sorted order. The default is 
to not save any ftistings. 


batch 3 Run BLDIF7 in BATCH modee The default is to run 
it locally. 


2010¢5 BLORH?7 PROCEDURE DESCRIPTION 


BLORH7 is an SES procedure file which compiles/assembies 
the modules which make up the A170 side of the Remote Host 
Facility and produces the updated RHA170R IJtibrary file 
containing the A170 relocatable Remote Host binaries. When 
RHAL7OR has been builts, BLORH7 will tink to produce the five 
absolute files which are added to the A179 NOS system 
deadstart tape to support the Remote Hoste This happens only 
if no MADIFY/compilation/assembly errors occurred during their 
respective phases. To be abte to tink successfullys the 
module must be recompiled/reassembled error-free. The tinked 
absolutes are added to the direct access file SYSBINS in the 
current catalog. The compilation/assembiy listings may be 
saved either on disk (file DSLIST) or on tapes depending upon 
the specification of the "LISTING! oar ameter. 


The format of the BLORH7 Is as follows? 


SES»BLDRH7 € m = ¢€ tist of module names> Jj 
{ ec = € processor option > ] 

{ ab = <€ alternate base file > J] 

{C area = < user name D ] 

{C tisting ? tisting = < tape vsn D> ] 
{ 


batch j 


m 3 The module name(s) of the Remote Host routines 
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to be compiled/assembled, The defauit is to 
compile/assemble all of the modules which make 
up A170 Remote Host, 


c t For a pew modules the processor option § for 
compiling or assembling the module. Specify 
'C=1" for CYBIL Cc modules and 'C=0? for COMPASS 
modules. The default is #Cs1t for pew modules,» 
and internally defined defaults (stored with the 
module name within the BLDRH7 procedure itself) 
for existing modules, 


ab ? The user's alternate base program library 
containing new and modified modules, The 
default is NEWDKPL, 


area 3 Optional catalog specification to add to the 
Search tist for files needed by BLDRH7. The 
default is the current catalog. 


fisting : «Specifying the keyword ‘'LISTING!* saves the 
assembly listings on the direct access file 
DSLIST. Specifying "LISTINGs<tape vsn>! writes 
the assembly fistings to the tape with the 
specified VSN In sorted order. The default Is 
to not save any tistings. 


batch 3 Run BLDRH7 in BATCH modee The default is to run 
it localty. 


2210.6 OSB3ILD PROCEDURE DESCRIPTION 


DSBILD ts an SES procedure file which bullds the dual state 
binaries XDOSTVE»s XRUNVEs and XTRMVE. A! assembly and CYSIL 
compitation listings are put on the direct access text library 
file DSLIST (one tisting per records each headed by the 
corresponding MADIFY deckname) and the three toad maps are 
appended to the compilation and assembly listings. 


The format of the DSBILD is as follows: 


SESe-DSBILD C ab = <¢ alternate base D ] 
Carea = < user name D> J] 
Clisting = keyword or keyword=z<tape vsn> ] 
{ batch ] 


ab 3 The userts alternate base program tibrary 
containing new and modified modules, 
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listing 3! Option to save a compilation tisting as a 
permanent file or to archive the listing to a 
tape. The default Is no tisting will be 
created. 


area ? Dption to obtain the PL specified by the "ABI 
Parameter from another user's catalog should it 
not be found in the current catalog. 


batch 2 Run DSBILD in BATCH modee The default is to run 
it tocallys 


2e11 UTILITY PROCEDURES 


2e1ll.1 NVEREP —- REPORT SYSTEM CONTENT 


NVEREP is a precedure which dynamically produces NOS/VE 
build content reports based upon build information contained 
In the Integration procedure tlbrary (PROCLIB)s or that 
generated dynamically by partner procedures. The reports are 
sorted according to auser supplied primary sort keys and a 
procedure defined secondary key which Is associated with the 
prinary sort key. The amount of information contained on the 
Integration procedure library is timited by the SES Command 
Language processor to eighty characterss but the procedure is 
sufficientiy generalized to work with expanded Information 
produced by partner procedures. These partner procedures are 
not of a generalized nature so as to be documented at this 
time (primarily due to a saries of deficiencies in the current 
CI tools and conventions). 


The format of the NVEREP procedure is as follows: 


SES -NVEREP CC left = < primary key > ] 

{ right = < primary key> ] 

{ area = < alternate user name > ] 
C f = < input source > J 

{ 0 = € output destination > ] 

{C ! = < tibrary name > Jj 

{C print ] 

{ batch ) 


feft : Primary sort key for teft side of two paged 
report. Onty the first two characters of this 
parameter are significant. May be either 
MOdules MAdifys Librarys or LAnguage. (An 
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additional options VErsions is onty available 
when used in conjunction with partner 
procedures, Option 3Uild is under consideration 
for future implementation.) The default for 
this parameter is MNdulee No validity checking 
is performed for either the tleft!' or tright! 
parameter valuess and an invalid specification 
witl result in a report which may differ from 
that desired. 


right 3 Primary sort key for right side of two paged 
report. See parameter feft for valid 
specifications. Default is MAdify,. 


area 3 Alternate user name to search first for the 
input file specified by the ‘'f* parameter, 
Default value Is 'null'sy» and source for 'ft is 
found in the user name where the procedure 
resides {PRCUNAM). 


f 3: Name of the file containing bulld content 
information. Default is PROCLIB. 


o 3 Name of the file to receive the two paged 
report. Default is VEREP. (The files LEFT and 
RIGHT currently remain tocal after the procedure 
has completed. These files contain the teft and 
right hand portions of the two paged report.) 


3 Name(s) of NOS/VE tibrary (or tibraries) which 
are to be included in the report. Default is to 
report on ail primary NOS/VE tibraries. 


print 3 Keyword to cause output file to be printed. 
Default is to not print the report untess batch 
@xecution has been selected, 


batch 3 Keyword tc cause the batch execution of the 
Procedure. Default is to run the procedure in 
*LOCAL*® mode. 


2elle2 PROCEDURE GET - GET A LOCAL FILE 


The GET procedure provides a "working copy” of a file (ie. 
one which can be written tos or read froms without concern as 
to whether the File is accessed as a OIRECT or INDIRECT 
file). Several user catalogs may be searched for the file by 
specifying a list of vaiues for the UN parameter. If a tocal 
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file already exists with the same name as that specified by 
the LFN or PFN parameters then the tocal file is either 
rewound or converted to aworking file. One message per file 
is issued to indicate the action performed on the filenames 
specified on the procedure call» The MF parameter specifies a 
filename upon which the working filles are to be appended. 

The format of the GET procedure is as follows? 

SES.GET { tfn = ¢€ focal filename > J 
{ pfn = < permanent filename > Jj 
C un = ¢€ user name > J 
C mf = < merge filename > J 
C aiona Jj 


ifn 3 Local fite name by which the file is known (may 
be a list of files), If no filename is 
specified for Itfns then the filename value for 
the PFN parameter is positionally used. A 
common usage of this procedure is as follows: 
SES.~GET (MYFILELsMYFILEZ» wee vsetc.) 
In the above procedure call the permanent files 
MYFILE1], MYFILE2» etc.» would be made  tocal 
working files named MYFILE1, MYFILE2, etc. 


pfn 3 Permanent file name to be made a local working 
file. If no filename is specified for pfns then 
the value specified for the LFN parameteris 
used, The fist of PFN values is matched 
positionaltly with the LFN specified valuess 
This is itttlustrated as follows: 
SES»GET (onestwo) (stufflsstuff2) 
The above procedure call) would create working 
files named ONE and TWO from the permanent files 
STUFF1 and STUFF2 respectively. 


un 3 An optional tist of user names to direct the 
search order for files which are currently not 
focal. This is conveniant if the user knows 
that the file exists in one of several 
catalogs. An exanple would be: 
SES~GET IPNDOC UN=Cintls int2sdevlsdev2sreil) 
The above orocedure cal! would search iocal 
files for a file named IPNOOC followed by the 
catalogs INTl» INT2» etce until the file is 
found or the search is exhausted. 


mf 3 A filename upon which to stack the resultant 
working files. For example: 
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SES.»GET CIPNDOCs8CR) MFsBUILDOAC 


The above procedure call gets the files IPNDOC 


and BCR as working filess then appends them 
the file BUILDOC. ITPNDGC and BCR remain 
working files along with BUILDOC, 


to 
as 


ainat 3: Keyword which determines whether the procedure 
should abort in FILE NOT FOUND) situations. 


Default is to REVERTsABORT,. 


2011.23 PROCEDURE SAVE - MAKE A LOCAL FILE PERMANENT 


Procedure SAVE may be used in conjunction with the GET 


procedure, The redeeming factor about the SAVE procedure 
that the user need not be concerned about file size. 


is 


The 


named local files are made permanent as INDIRECT access files» 


if possibtes otherwise DIRECT access files, This 
intentionally done to preserve as much orecious disk space 


is 
as 


possible. (NOS alfocates OPIRECT access files much tTIess 


frugality than INDIRECT access files.) Be forewarned that 
Slight penalty is imposed in access time for each sector 


a 
of 


disk space saved in this manners and that the actual sector 
savings is only visibie from the operator's console (not via 
CATLIST). In the procedure writer's wortd of Jlivings this 


Procedure negates the worry of predicting file size prior 


to 


creating it. Files are SAVE'd as SEMI-PRIVATE READ-ONLY 
filess unless changed via the CT and M parameter or profile 


variable values. 


The format of the SAVE procedure is as follows? 


SES «SAVE { ifn = ¢€ tocal filename > ] 
C pfn = < permanent filename > j 
{C ct = <€ catalog type D> Jj 
Cm ® < access mode > ] 
{ dir ] 
Caionaj 
{fn 3 Local filename to be made permanent. Defaults 


to PFN value if not specified, Parameters 


may 


be specified positionallys, and typical usage Is 
as follows: 

SES.SAVE (xIimmtrsxijlibs one getc.) 

In the above procedure call the Files 


XLMMTReXLJLIBs etc. are SAVEd as permanent 
files. <A message is issued to indicate the type 


of file created (DIRECT or INDIRECT). 
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pfn 2 Permanent Filename for files to be saved. 
Defaults to LFN ff not specifiede PFN vatues 
are matched positionally within the list to LFN 
values. This is ittustrated as follows: 
SES.SAVE (onestwo) (stufflsstuff2) 
The above procedure call saves files ONE and TWO 
as permanent files named STUFF1 and STUFF2,. 


ct 3 Catalog Type of the file when made permanent. 
Default Is to make filles semi-private (CT=S). 


m 3 Mode of the file when accessed. Defaylt is read 
access (M=R). 


dir 2 Keyword which directs the procecure to make atl! 
named files DIRECT access filess regardiess of 
their size. 


a ina Keyword which determines whether the procedure 
should abort if FILE [8S NOT A LOCAL FILE. 
Default is to REVERTsABORT. 


Zell e4 NVEMAP = REFORMAT NOS/VE LINKMAP 


NVEMAP is a procedure to reduce the number of printed pages 
of a NOS/VE Jlinkmaps while maintaining readabilitys and to 
provide summary reports of Information contained wihtin the 
jinkmap. Either alls or portions of the tinkmap may be 
processed, The reformatted form of the finkmap is also 
suitable for microfiches in the format defined for the NOS/VE 
operating system. 

The format of the NVEMAP. procedure is as follows: 

SESeNVEMAP € 4 &# <€ input file > 1] 
{Co = ¢€ output file> 1] 
{ area = <€ alternate user name > J 
{ copy = < record count > ] 
{ skip = < record count > J] 
{C print J] 
{ gated ] 
C fiche ] 
{C module ] 
{C save ] 
{ two ] 
{ batch ] 


i 3 Input file which contains generated output from 
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the execution of the NOS/VE CI (or SES) Linker. 
Default is MAPXX for the system. 


Oo 3 Name of the outout file to receive the 
reformatted Jinkmap file. Default Is to produce 
a ftocai file of the same name as specified by 
the "i * parameter, 


area Aiternate user name to search for the input file 
specifled by the 'i! perameter. Default value 
is fnutit. 


copy 3 Count of the number of NOS records to process 
from the current file position of the inout file 
(defaylt position BOI). Each invocation of the 
linker produces a naw record upon the output 
file. Thuss to orocess onty the first portion 
of the linkmap (typically Monitor for the NOS/VE 
Operating System) *COPyY21"' would be specified. 
Default value for this parameter Is to process 
the entire linkmap BOI to EOI. 


skip 3 Count of the number of NOS records to skip prior 
to processing. For the NOS/VE operating system 
'SKIP=2" would suppress the Monitor and ET 
portions of a Dual State tlinkmap. *SKIP #2 
CoPYs#1* would process only the Task Services 
portion of a Dual State f{inkmap. Use of elther 
the 'skip' or ‘copy! parameters infers explicit 
knowledge of the content the linkmap. Due the 
the number of variations of finkmap which can he 
produced it would be Impractical to generalize 
these parameters in a more fogical manner. 


print Keyword to cause output file to be printed. 
Default is to not print the reformatted 
linkmape. "PRINT TWOMAP! will print the contents 
of file named TWOMAP, Key PRINT? will print 
TWOMAP if key "TWO" is also specifieds otherwise 
the file specified by the 'o* parameter will be 
printed. 'PRINT#ALL!' will print both TWOMAP and 
the file specified by the to parameter. 


gated : Keyword which eliminates information for all 
entry points which do not have the GATED 
attribute. Conceivably», a combination such as 
*SKIP#2 COPY=1 GATED? would produce information 
to a compiler project about which entry points 
within Task Services are GATED for their use. 
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Default is to oeroduce reports of al! system 
entry points. 


fiche Directs the procedure to place the output of the 
Procedure onto the File NOSLIST for subsequent 
microfiche processing. Default is to not add 
the Jinkmap to the NOSLIST file. 


module : Keyword which causes the removal of all entry 
point information from the Jinkmap. This proves 
useful for auditing module attributes. The 
default is to retain atl system entry point 
information, 


save 3 Keyword which causes the output files to be 
retained on permanent files for subsequent 
Inspection. It is left to the discretion of the 
user to dispose of tocal copies of the output 
files, 


two Keyword which directs the procedure to twopage 
the Jinkmap onto the File TWOMAP. TWOMAP will 
always be generateds but will only contain the 
summary reoort information unless %twot is 
specified. This twopage option Is not the 
famitiiar SES TWOPAGE options but rather a 
computed split and merge of the reformatted 
Mape 


batch 3 Keyword to cause the batch execution of the 
procedure. Default is to run the procedure in 
*LOCAL® mode. 


This procedure wili always produce two output files. The 
primary output file is governed by the to* parameter. A 
secondary output *TWOMAP' is always produced as well. The 
*TWOMAP® File will onty contain the summary reports and 
foadmap if parameter 'twot is not selected. The first summary 
report which is produced is a two ovaged report of PVAs_ found 
in the Uitnkmap,. The left hand portion of this report ts a 
sort by PVA. The right hand portion of this report is a sort 
by module and/or entry point name. This report should answer 
the questions: 1. Given a PVAs in which module and/or 
procedure is that PVA contained?s 2. Given an entry point 
names in which module is it defined and what is its PVA?» and 
3e Given the name of a variable within a system defined 
tables what {fs Its ltocation within a dump? 


The final report is a two part error summary for the 
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linkmap. The first portion of this report identifies which 
pages of the linkmap contained one or more errorse The second 
portion of this report is a list of all of the errors found 
within the tinkmaps in the sequence in which they appear in 


the map. 
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2011.5 PROCEDURE FORMPROC - FORMAT PROCEDURE 


This procedure reformats a single SES or CCL procedure 
which is present on a GROUP file. Nesting levels of the 
procedure are used to compute a floating margin to indent 
statements contained within [F» IFE, WHILE, ROUTs or SKIP 
blocks. 


The first TOKEN of each tine is processed as follows: 

- IF a double quote (") then lteave the tine asts. 

- JF a backward stant (\) then orocess the second TOKEN. 

- IF a blank and DELETE boolean FALSE, then leave asise 

~ IF AND or OR, then this tine is continuation of SES IF or 
DORIF» adjust margins appropriately if INROUT boolean is 
FALSE. 

- IF a CCL IFEs WHILEs SKIP,» etc. and CCL boolean TRUE then 
adjust margins», and add blank lines as appropriate. 

- IF none of the aboves or a ROUT — ROUTEND block and DOROUT 
boolean is falses then teave line asis. 


The second TOKENs for lines having backward slant as thelr 
First TOKEN»s ts processed as follows? 

- IF a vatid SES reserved names then uppercase the TOKEN and 
adjust margins as appropriate. 

- IF not a valid SES reserved names then GENLOWR the TOKEN 
and SU8STR the value to a seven character value. (This is 
typicaltiy a statement assigning a value to a SES 
variable.) 


Conventions for spacing and indentation were established 
through trial and error with several complex procedures. Most 
all of the vatues which govern these conventions have been 
externalized as parameters and PROFILE variables to attlow 
tailoring to individual tastes. Blank fines are used to 
signify the start or end of a IFs ROUT, WHILEs or SKIP biock 
or to highlight the presence of INCLUDE, CYCLE,» ACCEPT, or 
EXIT statements. 


Special timitations are imposed upon procedures formatted 
by this procedure. If the formatted tength of a statement 
exceeds 79 characters (a SES restriction) then a terse 
diagnostic is issued and the Jine is teft unformatted. Each 
diagnostic or message issued indicates the tine number being 
processed as well as the line number being written. Thuss the 
growth or shrinkage of a procedure can be observed while 
formatting is taking place, Informative messages are issued 
to indicate when a new indentation “nest™ tevel has been 
reached. These informative messages are intended to give the 
warm feeling that the procedure is doing something. 
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The format of the FORMPROC procedure Is as follows? 


SES -FORMPROC € § = < filename D j 
{ 0 = < filename > ] 
{ control = ¢ string > ] 
{[ indent = < number D ] 
{C after = < number D> J] 
{[ blanks = < boolean > ] 
{ delete = < boolean > J 
{C cect = <€ boolean D> ] 
{ dorout * < boolean > j 


i 3 Input filename containing the procedure file 
source, Default name is GROUP, 

ot Output filename to which formatted procedure is 
to be written. Default is GROUP. 

control 3 A string which defines the SES directive 


character for the procedure to be formatted. 
Default is \ (backwards stash)» "commercial at" 
character cannot be used. 

indent 3 Number of spaces to indent from teft margin. 
Default value is two spaces (for unnested SES 
directives column 1 contains '\* and column 2 
contains a blank characters for CCL If» WHILEs 
or SKIP commands columns 1 and 2 contain blanks 
if the CCL boolean Is TRUE). 

after : Number of spaces to indent fines occurring after 
IF» WHILEs ROUT or SKIP statements. Nefault 
value is two spaces. 

blanks 2 Boolean which if TRUE causes the Insertion of 
blank tines into the formatted procedure (if 
needed). Default is TRUE. 


delete 3 Boolean which if TRUE causes the deletion of all 
unneccessary blank tines. Default is FALSE. 
cc! 3 Boolean which if TRUE causes CCL Cinctuding NOS 


Command Language Statements) to be indented 
along with other procedure statements. Defauit 
is TRUE, 

dorout 3 Boolean which if TRUE causes ROUT — ROUTEND 
statements other than SES directives to be 
formatted. Default is FALSE. WARNING?#!: A 
TRUE value for this parameter can create havcc 
with HELP documentation. 


Note: When formatting orocedures which contain onty CCL 
statements it is recommended that INDENT2*0 and BLANKS=FALSE be 
specified, 
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2011.6 PROCEDURE SIZES - REPORT MODULE SIZES 


This procedure uses partner orocedures NVEMAP and HEXTDEC 
to produce a “quick and dirty™ report of module sizes in 
decimal and hexadecimal tyte lengths from a VELINK tink map. 
Very Tittie sophistication has been worked into this procedure 
whose purpose is to provide data for the Maintenance’ Task 
Force In their analysis of Remote Maintenance techniques in a 
Binary Release environment. 


The format of the SIZES procedure is as follows: 


SES.SIZES { i = < filename > ] 
{ o0 = <¢ filename > ] 
C un = ¢€ user name > Jj 

i: Input filename containing a VELINK Link map. 
This parameter is required. 

Oo 3 Output filename to write report toe Defauit is 
same as input filename. 

un User name in which input file is to be found. 


Default is current user's catalog. 


2012 PRETINTEGRATION BUILDS 


During the Build CG timeframe, a smatl group of people 
consisting of 3 developers and 1 integrator formed the 
Pre-Integration Build Team, The purpose of this group is to 
ease and expedite the formal build process by turning around 
problems and generating fixes before a formal Integraticn 
build is performed. When a major features requiring a great 
deal of code and causing substantial impact upon the systems 
is ready for integrations the Pre-Integration Build Team goes 
to work on it first. The code is applied to the PL's in the 
Integration catalog (INT1)» and the entire system is compiled 
guiskiy in the pre-integration build catalog. Modsets are 
generated by this group to correct any compilation errorss the 
system is tinked and a deadstart tape is built for testing on 
the hardware. The regression tests are run on this systems 
and fixes are generated to solve problems found. When the 
Pre-Integration Build Team has fixed as many problems as it 
can or needs tos Integration makes its formal build in the 
Integration (INT1) catalog with the original code plus fixese 


In order to buitd the entire system in a timely manners 
pre-integration build procedures have been developed and are 
outiined in the following sections. 
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2012.1 GENDEK PROCEDURE DESCRIPTION 


The GENDEK procedure takes the latest list of deck names of 
each of the OS tibraries from the Integration PROCLIS (i.e. 
LMMTR»s LS1139 LJ23D» etce)»s and creates two files of MADIFY 
directives - one file (the last 4 characters of the Jibrary 
file appended to the string 'ADK!') contains a *EDIT directive 
for each assembier decks», and the other fite (the fast 4 
characters of the library file appended to the string 'CDK*) 
contains a *EDIT directive for each CYBIL deck. If a 
particular tibrary does not contain any assembier decks (or 
any CYBIL decks)» GENDEK will issue an informative message 
stating as muchs and no ADK__.. (COKL___) file will be 
created. The ADKLUUU/CDKL__U = =60f iles) will be saved in the 
current catatog for a subsequent BILOLIB run. 


The format of the GENDEK ts as follows? 


SES -GENDEK 


2012.22 BILOLIB PROCEDURE DESCRIPTION 


The BILDLIB procedure takes the ADK UU. and CDK. files 
(if they exist) for a particular tibrary (created by GENDEK)» 
and assembies/compiles all the modules for that tibrary. For 
each assembler deck on the ADK_-___ file a separate call to the 
C180 assembler is performeds and the packed assembled binartes 
are copied to the Jibrary file. The COK_.... file is used to 
make one call to MADIFY to write ali CYBIL modules to one 
compile files which in turn is fed to CYBIL. The CYBIL 
binaries are copied to the tibrary file following the 
assembler binaries» and the IJibrary file is saved in the 
current catalog. No compilation tistings are produced. The 
dayfile for the job is saved in the current catalog (the tlast 
& characters of the Jtibrary name .appended to the string "DAY*?) 
for input to the CHKLI8 proceduree The GENDEK procedure gust 
be run prior to a BILDLIB run. 


The format of the BILDLIB is as follows: 


SES-BILDLIB C tib = < ftibrary indicator > J] 

{ plu #® < user name > ] 

{ b = ¢€ PL name D ] 

{[ ab = <€ alternate base > ] 

C abu = < alternate base user name > ] 
{ 


local ] 


fib 3 The tast 4 characters of the name of the ltlbrary 


2-47 
ADVANCED SYSTEMS INTEGRATION PROCEDURES NOTEBOOK - Cycle 3 

| mn | | as 05/22/82 
2.0 OVERVIEW OF INTEGRATION PROCESS 
201202 BILDLIB PROCEDURE DESCRIPTION 


EL etka PERE EE PEPER EEE, EPR POPP RPE ee Ee ee SD ced Bed ede deka dinthieda dade dediadindndiaded 


to be built. This parameter is required. 


plu 3 The name of the catalog to search for the PL'*s 
and the compiler, The default is the 
<Integration> cataloge 


b 3 The name of a PL in the current catalog to 
include in the MADIFY PL search Jtiste This 
parameter is optional. 


ab. 3 The name of a PL In another user's catatog te 
include in the MADIFY PL search Jlist, This 
parameter is optional, 


abu 3 The name of the catalog to search for the PL 
specified by the 'A8* parameter. This parameter 
is required if the "AB! parameter is specified 
and Ignored if the ‘'aB* parameter is not 
specified. 


focal 3: Run BILDLIB tocally. The default is to run it 
in BATCH mode. 


NOTE: The modules RHMSINTERIM_SIMULATED_I10 (deck RHMSIO in 
library XLJ23D) and OCMSOMC_SIMULATED_IOD_ROUTINES (deck OCMCIO 
in Jtibrary xlLJB8B8B) will always have compilation errors. Both 
modules require common decks from CYBICMNs but Including 
CYBICMN in the MADIFY PL search !ist for these two libraries 
causes many more compilation errors in other modulese 
Currentiys these two modules must be rebuilt, after running 
BILDLIB for their respective ltibrariess, using the procedure 
NVEBILD (see the documentation for this procedure in a 
previous section), 


201223 BILDALL PROCEDURE DESCRIPTION 


The BILDALL procedure simoly submits a batch BILDLIB run 
for each of the OS libraries. 


The format of the BILDALL Is as follows? 
SES.BILDALL € ptu = € user name D J] 

{ b = ¢€ PL name > } 

{C ab = € alternate base > ] 
C 

C 


abu = < alternate base user name > ] 
batch ] 


piu 2 The name of the catalog to search for the PL's 
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and the compiler. The default Is the 
<Integration> catalog. 


b 3 The name of a PL in the current catalog to 
include in the MADIFY PL search IJist. This 
Parameter is optional. 


ab 3 The name of a PL in another userts catalog to 
include in the MADIFY PL saarch tist, This 
parameter is optional, 


abu 3 The name of the catatog to search for the PL 
specified by the "AB* parameter. This parameter 
js required if the 'AB* parameter Is specified 
and ignored if the 'aB* parameter is not 
specifijed. 


batch 3 Run BILDALL tn BATCH mode. The default is to 
run it ftocally. 


2012.4 CHKLIB PROCEDURE DESCRIPTION 


The CHKLI8 procedure uses the dayfile saved from a BILDLIB 
run (* DAY UU U® files see BILDLI8 description) to report any 
MADIFY/assembier/CYBIL errors, It simply uses XEDIT to 
extract the necessary informations which is displayed onthe 


file *"OUTPUT?, 
The format of the CHKLIB is as follows: 


SES-CHKLIB C tib = ¢ tibrary Indicator > ) 
{C batch ] 


fib 3 The last 4 characters of the name of the Iibrary 
which was built. This parameter is required. 


batch ! Run CHKLIB in BATCH mode. The default is to run 
it focally. 
2212.5 PURDEK PROCEDURE DESCRIPTION 
The PURDEK procedure simply eurges all the ADK ____» 
COK UU» and DAY ___. Files from the current catalog at the end 


of a pre-integration when they are no tonger needed. 


The format of the PURDEK is as follows? 
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SES .PURDEK 
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300 QUAL STATE_INSTALLATION SEQUENCE 


This section describes how to install all of the files 
needed to run NOS/VE in Ouai State mode. To do this from 
"scratch" the following materials are necessary: 


1 MSL tape 
1 Dual State NOS Deadstart tape 
- The LOADPF tape(s) which contain the NOS/VE environment 


If MSL and CTI are already present and corrects then it is 
only necessary to install a new deadstart sector on disk or to 
load a new NOS/VE environment. 


301 RELEASE_RESERVED SPACE _AND_INSTALL CTI 


WABNING-.__This._process.__should only. be done by the site 
analyst. 


To release reserved disk spaces, deadstart from the Dual 
State NOS Deadstart tape which is NTs D2PE, Fai» LB=KUs and 
enters 


U for the Utilities display 
I for Install CTI to disk 


-This dispfiay will appear: 


ENTER ONE OF THE FOLLOWING 
(CR) -~- INSTALL DEADSTART MODULE ON DISK 
R ~ RELEASE CTI-MSL/HIVS RESERVED DISK SPACE 


Enter R and this display will appear? 


RELEASE CTI-MSL/HIVS 
RESERVED DISK SPACE 


Enter the disk parameters as they are requested. 
CH 00 


EQ 00 
UN 00 
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-This disptay will appear: 


ENTRY OF CR WILL CAUSE RELEASE OF 
CTIVMSLJHIVS RESERVED DISK SPACE 


Enter a carriage return and RELEASE COMPLETE, (CR) TO 
PROCESS DYFFERENT DEVICE will appear. Enter a carriage 
returne: 


-The ENTER ONE OF THE FOLLOWING display will appear again; 


this time enter a carriage return. A WARNING message will 
appears; enter another carriage return. 


This display witli appear: 
INSTALL DISK DEADSTART MODULE 


Enter the disk parameters as above, The following messages 
will appears: 


INSTALLING CTI TO DISK 


INSTALL COMPLETE. 


32 INSTALL MSL 


~Deadstart from the MSL tape (CTI Is on the tape also.) From 
the *A* displays type in U for Utitities. From the *U* 
displays type in T for INSTALL MSL/HIVS TO RMS. 


-This display will appear? 
TDX 
DISK AND TAPE TRANSFER UTILITY 
CR TO CONTINUE 


Enter a carriage return and anter disk and tape parameters 
as they are requested. These parameters are for the disk to 
which ASL is to be foaded and the tape from which it is to be 
loaded. 


DISK CH 901 
DISK UN 00 


TAPE TYPE Q3 
02 60Xs1865Xs2266X»s 3267X 


TAPE CH 13 
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TAPE EQ 00 
TAPE UN 00 

-This disptay will appears 
A-BUILD MSL FROM TAPE 
B=-BUILD CB LIBRARY ON MSL 
C-ADD PROGS. TO MSL 
D-ADD CB-S TO MSL 
E-COPY PROGS. TG TAPE 
F-COPY CB-S TO TAPE 
G-DIS SYS TSLS 
Enter A and the following display will appear: 
MSL INSTALLATION OPTION 
AZHIVS 
BaMSLt/0S SHARED 
CamMSL/MAINTENANCE ONLY 
Enter Be 

~This display will appear: 


HAS A COMMAND BUFFER LIBRARY BEEN BUILT AT 
STARTING CYL 1420 THAT YOU WANT TO SAVE 
YeYES» NeNO 


Enter N» and the screen will show CHECKING STARTING 
CYLINDER» BUILDING SRT,» and BUILDING PNT. 


The next displays and corresponding entries are? 


COPY FROM 
~CR- = FIRST NAME 


Enter a carriage return. 
CTI ON TAPE (Y/N) 
Enter Y 


COPY THRU 
“CR=- = LAST NAME 


Enter a carriage return. 
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DATA VERTFY (Y/N) 
Enter N- 


“~The MSL Tape will toad at this point and this display will 
appears 


LAST USED 
CYL 1l4nn TRK 0000 SEC 6000m 


303 CMRDECK_ CHANGES AND _CMDSL_EILE 


303061 NOS CMRDECK AND LIBDECK CHANGES 


ae When deadstarting NOS to run a dual state environment» 
it Is required that one or more of the following 
commands be processed by the NOS CMRDECK command 
processor. The command(s) which must be specified by 
the operator will be dictated by the type of NOS 
environment which is to be supported during dual state 
operation. 


MINCMEXXXXXe The parameter 'xxxxx' defines 
the minumum amount of central 
memory words which NOS will use 
for the following operating 
system execution. The parameter 
is an octal value expressed in 
multipfes of 100. If this 
command is not specified the 
system assumes a default of 
30090900(8) or 98K(10) central 
memory words. 


VE. This command establishes a Dual 
State Communication Block (DSCB8) 
in NOS Central Memory Resident 
(CMR). The OSCB is required to 
enable the operator to deadstart 
NOS/VE. 


VEBKXKXXK This command establishes a DSCB 
in NOS CMR and also reserves, 
for use by NOS/VE» the number of 
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central memory words expressed 
by the parameter *xxxxx'. The 
parameter must be an even number 
and is an octal value expressed 
in multipies of 1000. 


EQxx2=DE,ST,0PsSZsFD.-This command Is required if UEM 
(soft €CS) is to be used by 
NOS. The SZ parameter is an 


octal value (minimum of 10) 
expressed in multipies of 1C0C. 
The remaining parameters are 


defined in the NOS Instattation 
Handbook, NOTE: If this command 
is specified in the NOS CMRDECK, 
it is mandatory that the 
VEZxxxxx, command be specified 
if NOS/VE will be deadstarted. 


The atgorithm used by NOS to determine if the memory 
size parameters specified by these commands are fiegal! 
is? 


(Machine Field Length) >= (MINCM + UEM + NOS/VE) 


Some examptes of how to use these commands when 
deadstarting NOS for execution iin a dual state 
environment are as follows» assuming a 1648 mainframes 


VE. No UEM and the default 
MINCM will be usede NOS 
will atlow NOS/VE to use 
atl but 98K or  3002000(8) 
words of the machine field 


length. 
VE. No UEM and NOS will allow 
MINCM#10000. NOS/VE to use all but 262K 


or 19000,s000(8) words of 
the machine field tength, 


VEs5000. No UEM and NOS will allow 
NOS/VE to use a maximum of 
1OMB or 530002000(8) words 
of the machine field 
length. NOS will use OMB. 


VE=s5000. NOS wittl altow NOS/VE to 
EQ5=sDE,ST,OPs2CG0sFD. use a maximum of 10MB~ or 
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53000,000(8) words of the 
machine field ltength. NOS 


will allocate 4M8 or 
29000,000(8) words for UE™ 
and wiid use 2M8 er 


12000,000(8) words for CM. 


be. All CM2 tines should be deleted as all memory allocation 
is dynamic. 


ce All NOS/VE mass storage davices must be specified in the 
N95 CMRDECK as DOWN devices» CeCe 
EQnn2DQ—19 D0 WN 9094692. 


de The disk controlware that NOS toads to FM type 
controllers at deadstart is the correct controitware for 
the NOS/VE 7155-1x disk controlters. Add the following 
line to the CmMRDECK to cause controlware to be ftoaded to 
both the NOS and NOS/VE disk controllers: 
LBCaFMschlsch2Zsch3. {The chi are disk channets as 
appropriate.) 


ee The NOS LIBDECK must be modified to include the new 
procedures necessary for deadstart. *PROC SETVE and 
*PROC OPERFAC must be added and *PROC UPMYVE should be 
deleted. 


30362 CMDS1 FILE 


ae A feature has been added to Cycle 3 to jdImprove the 
transportability of the DSTVE directive file CMDS1. If 
*MEMORY#0. jis entered in CMDSl»s OSTVE will always 
request all avatlabie memory from A170 NOSe It Is 
essential with this feature to enter In the NOS CMRODECK 
the entry MINCM=#10000. to prevent NOS from giving 
NIS/VE so much memory that 4170 NOS will not run well. 


be The default value for the NOS/VE system device disk 
channel is specified on the following command in the 
CMDS1 fite: 
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¥*SYSTsDSPANELsOFFFOO( 16) ac. 


This means that it is no tonger necessary te 
rebuiid IOPQUER to connect the NOS/VE disk to 
the proper channel. 


ce The default value for the NOS/VE deadstart command file 
number (DCF) is specified on the following command in 
the CMDS1 file: 


¥*SYST»DS PANEL »sCFFFFF(16) =n. 


de The channel number x in the following command should be 
an empty channel: ¥*RELOADCH=x, 


e» Debus flag number 2 should be TRUE to enable recovery to 
work automaticallys, e.g. *SYSTs»sDEBUGZ=#TRUE. 


30% INSTALL_SYSTEM 


Deadstart from the NOS Dual State deadstart tapes using the 
deadstert tape which is to be instatltied. Choose the '"Qg? 
option on the first displays for operator intervention. 
Optionaitlys the 'P* display may be selected to choose a 
CMRDECK, (CMRDC14 contains the CANCDD S2_ configuration» 
CMRDCKS contains the ARHOPS $2 configuratione) Hit carriage 
return. The system wil! display? 


ENTER LOCATION 
OF MSLYHIVS DEVICE 


Enter the Information for the same disk where MSL was 
instaltied previously: 


Channel =xx 
Equipment=x x 
Unitzxx 


After the system is deadstarteads enter the following 
commands 2 


XeDLS. 
COMMONSSYSTEM. 
INSTALLs SYSTEMSEQxx. 
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NOTE: xx is the EST ordinal of the disk where the deadstart 
sector is to be installed; this is the same disk where MSL was 
installed previously. 


305 LOADPE_FILES 


The LOADPF tapess which are NTs D=PE» FSI» and LB=Kl» 
contain the NOS/VE operating system source and binariess tools 
to assemble and tink the operating systems and various other 
files. 

Deadstart from the disk upon which the NOS Dual State 
system was installed and LOADPF the files to the desired user 
number. 


366 BRING UP DUAL STare 


Refer to the current Helpful Hints documents Section 49 for 
information regarding the operation and execution of NOS/VE. 
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4.0 NOSAVE_HARDWARE REGRESSION TESTING 


401 INTRODUCTION 


The verification currently performed on NOS/VE systems 
consists of running the $2 Regression Test Sequences as 
outlined in the fotlowing sectionss on the hardware. 


4.2 S2_BEGRESSION_IESIS 


Ge2el jOB2 


JO82 is a file containing the NOS/VE commands which stage 
an II ftibrary and a CI user job object file from the 170 side 
to the 180 sides convert the CI user job object file to an II 
object files and then foad and execute this user job with the 
library. It then stages the LOADMAP back to the 170 side to 
be printed. J082 tests the following NOS/VE features: 

LINK USER command 

SET_OBJECTLLIST command 
SETLPROGRAM_OPTIONS command 

GETPF 856 

GETPF B60 

CITOII conversion 

Load/Execute User Program + Library 
JMROUTE C180 print file 

SUBMIT of batch job 

SJMEXIT 


The command sequence follows: 


LOGIN USER*DEV1 NAME=J0B2 

LIUsUSER ® (DEVI sNVE) sPASDEVIXs AZNOTUSE Ds PReNOTUSED 
GETsVEWLIBRARYsCYBIILBssDEVIeNVEs3B56 
SETLIBJECT_LIST sADD=NEWLIBRARY 
SETL-PROGRAM_OPTIONSs LOADM AP» oo. 
MOS(BLOCKsENTRY_POINT sXREFsSEGMENT) vseoe 
TERMINATION _ERROR_LEVEL#FATAL 
GET»sXPETESTsXPETEST»s »sDEVI»sNVEs 860 
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EXECUTEs s*XPETESTsLGO*s»sCITIITI 
EXECUTE £60 
JMROUTE, NOTUSED sL GADMAP»PR 
SETLOBIECT_LLIST,»DELETE=ALL 
GETsCYBILIBsCYBIILB,s sDEVIsNVE,B56 
SET_PROGRAM_OPTIONS LIST1 TERMINATION_ERROR_LEVEL=ERROR 
EXECUTE LGD 

JMRBUTE sNOTUSED sLIST15PR 
GET»JNB3sJOB355 »NVEsA6 

SUBMITs JO83 
GETsJ0B4sJ084595 »sNVEs AG 

SUBMIT,» JOB4 

JMEXIT 


4e2.2 J083 


J9B3 is the same NOS/VE procedure file as JOB2 and tests 
the same NOS/VE features with one addition: instead of doing a 
GET of the II version of CYSILIB from the 170s JOB3 does a 
NOS/VE permanent file ATTACH of CYBILIB from the $SYSTEM 
catalog. 


The command sequence foliows: 


LOGIN USER*DEV1 NAME#J083 

LIUsUSER#e(DEVLlsNVE)» PA=DEVIX,AZNITUSED »s PRENOTUSED 
ATTACH SSYSTEM.CYBILIB NEWLI3RARY 96 oe 

ACCESS _MNDE#(READ sEXECUTE) 
SETLOBJECT_LISTs»ADD=NEWLIBRARY 

SET PROGRAM _ OPTIONSsLOADMAP » wee 
MOe(BLOCKsENTRY_POINTsXREFsSEGMENT) pave 

TERMINAT IONLERROR LEVEL*FATAL 
GETsXPETESTs XPETEST»s sDEV1»sNVE» 860 

EXECUTE s s*XPETESTsLGO'%s,,CITOLI 

EXECUTE LGO 

JMROUTE sNOTUS ED sLOCADMAPs PR 
SETLOBJECTULISTsDELETE=ALL 

RETURN NEWLIBRARY 

ATTACH $SSYSTEM.CYBILIB ACCESS MODE=(READs EXECUTE) 
SETLPROGRAM_OPTIONS LIST] TERMINATIONLERROR_LEVELZERROR 
EXECUTE LGO 

JMROUTE sNOTUSEDsLIST1 PR 
SETsTESTBAMsTESTBAMs »sNVE» AS 

SUBMITsTESTBAM 

JMEXIT 
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42.3 JOB4 


J0B4 is a File containing the NOS/VE commands which execute 
the NOS/VE SETUP command to set up the 180 job environment 
{see Appendix D for the description of the SETUP command)» 
followed by a cCITOII conversion of a 170 object file user 
program and an EXECUTE of this programe The l!oadmap is staged 
back to the 170 side to be printed. J0OB4 tests the following 


NOS/VE features: 
CONNECT_LFILE command 
SETUP command 
CITOII conversion 
SETLUPROGRAM_OPTIONS command 
Load/Execute User Program + Library 
JMROQUTE C180 print file 
JMEXIT 


The command sequence follows: 


LOGIN USER*DEV1 NAME#J034 

CONNECTLFILE $ECHO OUTPUT 

SETUP DEV1 DEV1X 

CITOIT (I=LGO CLl=XPETEST USER =DEVI 

SETLPROGRAMLOPTIONS LIST1L TERMINATION_LERROR_LEVEL#ERROR 
EXECUTE LGO 

JMROUTE sNOTUSED sLIST19PR 

JMEXIT 


4.264 TESTBAM 


TESTBAM Is a file containing the statements necessary 


to 


execute all of the BAM test cases supplied by the BAM 


project. These procedures exercise various portions of 
basic access methods and are used to show some tevel 
confidence that BAM works as well as It has previously. 


The command sequence follows: 


LOGIN USER®DEV1 NAME®=TESTBA™M 
LIUsUSERs(DEVIsNVE) »PA2DEVIX »sA=NOTUSED» PR*NOTUS ED 
COLLECT_TEXT BAMINP 

TES1 

TES2 

TES3 

TES4 

TES5 


the 
of 
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TES6 

TEST 

TESS 

TES9 

TES190 

TESI1 

TES12 

TES13 

TES14 

TES15 

TES16 

TES29 

TES21 

TES22 

TES23 

TES24 

TES25 

TES26 

TES27 

TES28 

TES29 

TES31 

TES32 

TES33 

TES34 

TES35 

TES36 

TES37 

TES38 

BAMST OP 

ex 

ATTACH $SYSTEM-SYSLIB SYSLIB ACCESS MODE=(READs EXECUTE) 
ATTACH SSYSTEM.CYBILIB CYBILI8 ACCESS_MODE=(READS EXECUTE) 
SET_OBJECTLLIST ADD#=(SYSLIB,CYSBILIB) 
EXECUTE» » *BAMINP!# sso BAMTEST 
GETsSCLIB8OsSCLIS0s»»NVEs AS 
SUBMIT» SCL1890 

JMEXIT 


4e3 S2_REGRESSTON TEST _SEQueNce 


1) Deadstart A170 NOS: 
- Set the deadstart panel to disk deadstart froms 
CHel 
UNIT #41 
WORD 1320006 
- Push deadstart button. 
- Setect *0* disolay. 
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Hit carriage return, 
Enter date/time. 


2) If necessary, update the INT2(DEV2) catatog and toad 
the latest system files into the INT1I(DEV1) catalog: 


Mount the INT1L(DEV1) and INT2(DEV2) catalog DUMPPF 
tapes. 

X.DIS. 

USERs INTLIDE VL)» INTICDEV1) X. 

SES eUPCATS <WCstpyl> <SCz=tpu2> <SYSEDIT> 

Hit *." to go into AUTO mode, 

DROP, 


The SES.UPCATS procedure works as follows: 


ae Updates the INT2(DEV2) catalog by 
retrieving OSLIB»s SYSLIB,s, COLLIBs and 
CYBIILB from the INTLI(DEV1) catalog and by 
foading selected files from the DUMPPF tape 
mounted on the unit specified by the "SC" 


parameter. This parameter must be 
specified for the INT2(DEV2) catalog to be 
updated, 


be LOADPF's the tatest system into the 
INTL (DEV1) catalog from the DUMPPF tape 
mounted on the unit specified by the “wc 
parameter (defaults to "50"). 


ce SYSEDIT's the A179 Remote Host and 
Interactive binaries if the "SYSEDIT™ 
keyword is specified. 


Ge LOADPF's the Confidence Test binaries from 
the file CONFTST»s and then purges CONFTST 
from the catalog. 


3) 8riting up A170 Remote Host and Interactive: 


TAFNVE. 


4%) S8ring up dual state? 
Make sure the NVE Subsystem Environment is set up? 


X-SETVE(DEVIsUN=DEV1,C=6) Then bring up the NVE 
Subsystem? neNVEDEVI. (where nis any free NOS 
contro! point) 


5) When the NVE control oolint requests the Operator 


ne 
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Facility control points do: 
Kan, (where n is the OPFAC contro! point) 


6) Bring up NAM: 
FNC5,s7700. 
NeNAMS2. (where N #2 2 is NAM control point) 


7) Buitd and save the 180 object files needed to complete 
deadstart of NOS/Ve Cand needed to perform subsequent 
deadstarts of this system)» and begin execution of the 
180 system tasks to support Interactives Remote Host» 
and the dayfile displays: 

KeLIU (DEVI»sNVE) DEVIX. 
KeGETF DS 
K.DS TRUE FALSE FALSE TRUE SIF#TRUE. 


8B) When the system displays the message WREADY FOR 
COMMANDS", start loading the Confidence Test Base into 
the system (see Section 4.5 below). Make sure that the 
ASCII printer is ready» Jee. that the START light is 
tit and that a “FORM335TM.”" has been entered. To 
Monitor the 1890 jobs as they enter the systemsedo K.VED 
CP to bring up the NOS/VE control point display. 


9) The system is now ready to be taken downs 
NeCFO.DI»NE. {N is the NAM control point; this 
disables NAM) 
2eSTOP. (Bring down 170 Interactives Remote Host» 
and Operator Facility) 
Ke*BYEVE. (Bring down NOS/VE) 

IMPORTANT? This fast step must be performed at the NVE 
Subsystem K displays NOT the Operator Facility « 
display. 

When aff control points are "quiet", proceed to the next 
step. 


10) Bring down A170 NOS? 
AB. 
CHECKPOINT SYSTEM. 
Ey Me {make sure that all checkpoints complete) 
STEP. 


404 INIRODUCTION TO CONFIDENCE TESTS 


The confidence test base is a set of testssused to 
determine if a build is readys for installation in an closed 
shop environment. The test base consists of a set of tests in 
gach area of the operating systems oresentiy under analysis by 
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the evaluation unit. The tests are described in section 4.7. 
Any aquestions or problems should be addressed to Re Es 
JarosZ» x5834. 


405 INSTALLATION 


The following procedure should be followed when installing 
this test base. 


Le REQUESTsTAPEsVSNeCNFETAPSNTsD=> Es LBakKLy Fuls PORR, 
2e LOADPF»B=TAPEsTY=ALL 
This wit! install two files. 
1. The test source PL (CONFPL) 
2e¢ The SES procedure library (CNFPROC) 
3 Load any files from a tape created with the CLEANUP 
procedure. 
4, Two variables must then be added or changed in the user 
PROFILE. 
They are as follows. 
\ USEBIN = #OLD! 
\ RUNLVL = "DEV1! 


For more information on these orofile variables refer to 
sections 4.8.2 and 428.4-. 

At this point the confidence test base is instajlied and 
ready to be runs 


406 EXECUTION 


Before the tests are executed it is necessary to establish 
the ACR routines which collect the test resuitse Because of 
the changess that are on going in ACR» the routines will 
remain under the control of the Evaluation Unit. To use ACR» 
do the following before executing any tests. 


1. GET, ACRJOB/UN=EVAL. 
22 ROUTE sACRIJOBsDC#IN. 


You are now ready to execute the tests in the confidence test 
basee To begin do the following? 

SESsLPFNSCNFPROC.LOTB 0#(3A001.-eRHO2Z21) BeCONFPL OLD»s.. 

ee? DELAY#20 


At this points you can run test IF9094 by following the 
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instructions in section 4e5e1 of this document. 


After all the tests haye completeds do the following 
replacement of ACR results files to the 170: 


GET» JOBL/UN=DEV1 
ROUTE» JOB81»DC#= IN 


At this points run the RESLTS orocedure to recieve the ACR 
results listing. 


This job witt also produce a18CG listings of the system 
statisticss for comparasion purposes, 


SES,UNwEVALeRESLTS I=RESULTS O2= isting File 


4.6.1 EXECUTION OF IFO94 


This test is somewhat different in that it requires running 
by hand under NOS/VE IAF. To execute this test do the 
following. 


On NOS 
SESasLPFN=CNFPROC.GENBIN D=IFO94sBzXIFO94s oe 
PL=CONFPL»sCI»S#180s0LD 
This will create the object code part of the test, 
ON NOS /VE do the following: 
ATTACH_FILE .JEVAL.EVAL_SETUP 
INCLUDELFILE EVALUSETUP 
ACR TESTLNAMESIFC94 PRODUCT_LIDENTIFIER=IF 
GET_LFILE TO=XIFO94 DATA_CONVERSION=3B60 
EXECUTE_TASK PARAMETERS=*XIFO94sLGOt»SPaCITILI sLIBRARY2#SYSL 
LGO 
At this point do what the program tells you to. 
If you feel it performed as expected do the following? 
ACR STATE#PC REPORT#=TRUE ACTION=FULL 
Otherwise 
ACR STATE*FAIL REPORT#TRUE ACTION=FULL 


4.7 TESTS 
TEST TEST FUNCTIONS 
KKKKEKE Ter Tres Ses es 


BACCO] AMPSEFILE 
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AMPSGET_FILE_ATTRISUTES 
BAOD24 AMPSGET_DIRECT 
AMPSPUT_DIRECT 
BAQ27 AMPSGET_NE XT 


AMPS$PUT_NEXT 
AMPSGET_PARTIAL 
AMPS$PUT_PARTIAL 

BA048 AMPSGET_SEGMENT_POINTER 
AMPS$GET_SEGMENT_POSITION 
AMPSGET_SEGMENT_EOI 


BAOQ55 AMP$GET_FILE_LATTRISUTES 
BA062 Copy 
CHOO1 PMPSESTABLISH_CONDITION_HANDLER 


PMPSDISESTASLISH. COND HANDLER 
PMPSCONTINUE_TO_CAUSE 


CLO29 DISPLAY _VALUE 

CL039 DECLARE_VARTABLE 

CLO58 EXITs CYCLE 

CLO61 IF CLAUSE 

CL103 FILE CONNECTIONS 

L0034 BASIC LOADER OPERATIONS 
LD037 PMPSEXECUTE 

00044 RETAIN IN CREATE_OBJECT_LIBRARY 
PF101 VERIFY FILE CYCLES (DEFINE) 
PF125 VERIFY LFN»sPFN RELATIONSHIP 
PF140 VERIFY FILE CYCLES (PURGE) 
PF145 CHANGE 

PF156 DEFINE _ CATALOG 

PF157 PURGE _CATALOG 

PMO16 OSPSAWAIT_LACTIVITY_COMPLETION 
PMO50 JOB LOCAL QUEUES 

QF100 SUBMIT 

RHOO1 GET B60 

RHO11 REPLACE A6 

RHO14 REPLACE AB 

RHO21 GET 856 

IF094 VERIFY CONDITIONAL BREAKS 


INTERACTIVE INPUT/DUTPUTS 
TERMINAL ATTRIBUTES 


NOTE: ITFO94 MUST BE EXECUTED BY HAND. SEE Section 4601. 


4-8 TOOLS 


This section describes the ACR and SES proceduress used by 
the testss in the confidence test base. 
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4.8.1 AUTOMATIC CHECKING ROUTINES - ACR 


The 180 common ACR is described in the Interim Test Tools 
ERS. (D0CS number ARH4207) 


4.8.2 LOTS 


This SES procedure is used to toad a set of tests into the 
170 Inout queues from a Madify source program tItbrary. The 
parameters are shown below, 


DECK ? Dt: This required paraneters is a tist of deck names 
that are to be expanded and loaded. This parameter may be 
a fists arange or both, S8ecause these decks are expanded 
by MADIFY they can not be common decks. 


PL ${ 8: This required parameter Is the library where the 
decks listed on the preceding parameter reside, 


DELAY: This parameter specifies the number of seconds 
between submission of jobse If it is ommitteds 60 is 
assumed. 


UN3 This parameter is the user number where the program 
fibrary specified on the PL parameter resides. If it is 
ommitteds the user number of the executing job is 
utilized. 


OLD $ NEW: This keyword is used to replace the profile 
variable USEBIN. This profile variable is used by the 
GENBIN procedure (see Section 4.8.24). This parameter allows 
for a decisions to be made at execution times on whether or 
not to create any binary filles needed with this teste 

The default is NEW. 


PRINT 3 NOPRINT: This k@yword determines if the 176 output 
file is printed or not. The default Is NOPRINT. 


4.8.3 CLEANUP 


When tests use the GENBIN procedures to create CI object 
codes two files are created (DUMPDIR and PURGEF). The CLEANUP 
procedure uses these files to archieve the object code files 
and purge theme The parameters for CLEANUP are shown below. 
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VSN? This required parameter Is the VSN of the tapes where 
the DUMPPF is done. 


KL §$ KU: This optional keyword describes the tabel 
characteristics of the tape specified above. The default 
is KL. 


NOTE? The following table shows the other characteristics of 
the tape specified on the VSN parameter, 


TRACK NT (nine track) 
DENSITY PE (1600 bpi) 
FORMAT I (internal) 


The file written on this tape can be reloaded using the LOADPF 
UTILITY. 


428.4 GENBIN 


This procedure optionally creates a CC or CI object file 
fron an expanded cybili source file or MADIFY deck. The 
Parameters are shown below, 


D3: J ¢ ALL: This is the Fist of MADIFY decck names to be 
expanded and compiled, 


PL: This parameter is the library where the decks specified 
on the previous parameter reside. 


AB $ APL! This optional parameter describes the 
user numbered file names» to be considered as alternate base 
for expansion of decks or source fillese 


JN: This optional parameter is the user number of the file 
specified on the PL parameter, 


SF: This parameter Is an optional fille names telling the 
procedure to work from a source fjle instead of a MADIFY 
decke 


CFt This Is the file name where the expanded deck will 
resides and it is the input file to CYBIL. 
The default is COMPILE. 


L 3: This is the file where the CYBIL compilation tisting 
{s placed. The default is LISTING. 
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SYS : S$? This parameter causes a specfic file to be used as 
a ajternate base as shown by the following table, 


SYS FILE 


; 101 ; CYBICMN/UN=SES : 


ED CED A ND ED ee a ED en ee a ee a a ee ee ee ee 


; 170 : CYBCCMN/UN®SES ; 
; 180 ; OSLPI/UN=Iv1 ; 


LVL: This optional parameter is the tocation of OSLPI that 
will be used as an alternate base. The default is either 
the profile variabie RUNLVL or DEV1. 


BIN $ Bt: This required parameter is the name of the file 
checked for when the keyword OLD is specified. It Is 
also the name of the file where the object code will 
reside if NEW is specified. 


Cc $ C{L: This parameter is unique In that the value is 

used along with the keyword. If Just the keyword is coded 
the proper compiler is recieved from a default user number. 
If the value is coded the proper compiler is received from 
the used specified. The default user number is either the 
value of the RUNLVL profile variable or DEV1. The default 
vatiue for the keyword is CC. 


NEW $ OLD: This keyword determines if the object code file 
coded for the 8 parameter will be produced or not. If NEW 
ts coded the file coded on the 8 parameter will be created. 
If OLD is coded and the file exists then that file willl be 
used and no compilation takes place. If the file does not 
exist then the file will be created, 

The default value used is taken from the USEBIN profile 
variable, 
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4.8.5 PRTILIST 


This procedure is totaliyv internal to the tests and the 
discussion is teft to the help File. 


A: 


Bt 


Al 


05/22/82 
Originator ww weewenee DATE LuLu ufo Transmittal Noe clu 
Code Location: (PACKed Modsets) FNe www ON 
(Decks in "GROUP" format) FN2__ 99 UN*_______ 
Code Description File? EE 2) | eee Rem Ee ||, | Sen naan ne 
IF module has a call bracket of D GR 
code affects system user in some other way THEN 
Usage Changes Desc. File: FNe Lo UNe®LL eee? 
Code Destination (if not NOSVEPL)I® PL= oo 
ModSet Tdentitierts) 9 cg oe ee ee Ge ee eee seas 
New Feature Cow] OR Corrective Code C€._.] 


Module(s) to be recompiled 


How has this code been tested? (Use right margin.) 


COMMENTS TO_INTEGRATION 
NOTE? If any of these are checked», then explain in right margin. 


Instalitation procedure changes required? [20 

Dependent upon other features fixs, or tool? C_-..] (List below) 

OSLPI or Internal Interface changes required? ees | 

Should GNVEMT (Generate NOS/VE Message Templates) be run? Te | 

Notes.cegacding. code submittal: 

More forms are on FN = XMIT10 UN = DEVI. 

* Attach copy of description file to form (both 14 7/8 by 11). 

Format ist #MODSET_LIDENTIFIER (or NEW_DECK_NAME) (upper case) 

£PSR Number (Omit If feature code.) 
Descriptive text which describes code content 
**DECK MODIFIED (or NEW_L DECK NAME) (upper case) 

** Attach copy of Usage Changes Descriotion File to form 

(both 14 7/78 by 11). 


AITACHMENT. sy ame DEPENDENCY LISI 
Description Fil ssatates = 

Proof of Conotistient. 
Proof of Execution [€ 


] 

] ‘aie 
ues = 

j i . 

7 (Continue in right margin) 


Files maintained by Integratio 


Source Files 


ani aia acon pce wee es eee aes 
i USER : 
+; NUMBERS + FILENAME(S) 
fp ce oe 0 ae ce 00 ee cn ee 0 ee ee a ee ee 
H ; 
$ INTI/INT2 ¢ NOSVEPL 
$ DEVI/DEV2 3 
; ; 
: 
Sec ee ee we eee en hp 08 ee ee en ae ee ee ee ee ee ee 
+ INTI/INT2 $ OSLPI 
$ DEVI/DEV2 $ 
8 a 
e 8 
: 
he il eh shape ew ace Biss es ees cence ad eee eal 
; INTL/ INT2 + VELZOPL 
s DEVI/DEV2 ; 
4 
ee ee ee oe ee cee ee am en oe oe ee ee ee ee eee 
: ; 
+ LIBRARY + OPL 
8 a 
4 s 
$eeewee nen ¢Seee sees esses 
INTL/INT2 2 SESPLIB 
DEVI/DEV2 ; 
a 


8 
8 
; 
a 
8 
8 
] 
8 
a 


n 


MADIFY program {tibrary 
of Virtual State code 


MADIEY program gears 
of NOS/VE Program 
Interface decks, 


AD ED EY ND ND A A ND RE A NO SE OD HD RD cee ND AD AE TP ED MANY ee 


MADIFY program library 
of NOS code which 
supports NOS/VE. 


MODIFY program dibeacy 
which matches NOS 
system level for 32, 
(Installed on FMD 

unit 43). 


' 
| 
t 
' 
i 
i 
' 
j 
i 
i 
! 
t 
| 
i 
! 
j 
i 
| 
i] 
t 
' 
i 
‘ 
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Command Language 
Procedure Library 
(Documented in 
Integration Proced=- 
ures Notebook). 


rl 


$ magnetic fisting files 


tape 


oe 20 e@ wa © 


i a a a ab ae ob a a nD ove dhe ED A EE EO ee seme EE TORE RN AE Me AG eh ee cae om 


oe we Be Be Of Be Ce bh CO ow 88 we oe we G we HO oe He 


INTL/INT2 $ MTRXLCBs 
DEVI/DEV2 $ EILCBsSYSXLCB 
? JOBXLCB »BBBXLCB 
® 
: 
—— aa oe ee Se eee 
INT1 : NEWDKPL 
DEVI : 
: 
; 


ae 88 18 we C8 88 we } OS ce HO 2e 86 we we Oe 44 48 we 


Contains compiltation/ 
assembly listings of 
ali Virtual State 
code. Accessed via 
LISTNVE procedure. 


ee ee ee, eked ee, ee ee ee ee ee ee ee ee ee Se 
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VERSTON/FREQUENCY DF UPDATE 


i 
i 
i 
j 
i 
t 
i 
| 
i 
t 
i 
i 
i 
i 
' 
t 
1 
' 
i 
| 
j 
{ 
i 
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t 
i 
i 
! 
i 
| 
i 
! 
{ 
i 


latches the tevel of system 
inarles contained in same 
atalog.e. Updated on periodic 
cee baste 

Nabohes the jever of system 
inaries contained in same 
atalog. Updated once for 
ach bulld cycle. 

Watches the level of eyetie 
inaries contained In same 
atalog. Updated on 
periodic scheduled basis. 


Alay Atay TUNE EE NS EN A ND OS A “ED ED ED OD ORD NE SED ED OD 


Updated on a scheduled basis. 
(CPUMTR which supports NOS/VE 
is on VE17OPL and not 

on this PL). 

Matches the level of system 
binaries contained in the same 
catalogs and accesses the 


appropriate build tool 
versions. Schecuted updates. 
Matches the tevel of system 
binaries contained in the 
same catalog. 


Linker directives files 
for monitors 
error interfaces 
system corey job 
templates and user 
modules respectively. 
eaningless Madify 
rogram library 
hich users may 
ubstitute for 
AS an alternate 
ase when using 
ntegration compitlaticn 


ob ne oe Oh ae ae ee Hp 68 oe ee ee os « 


Matches the level of 
system binaries contained 
in the same catalog. 

EI is built using the 
BLDEI procedure. 
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: INTL/INT2 $ PMPXX 
+ DEVI/DEV2 £ PMPXXYY i 
H 2 RMPXX 
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: 
: 
i : 
$m e ee $ oe eee eee + 
t INTL/INT2 $ PSYXLOR 
{ DEVA/DEV2 $ RSYXLDR : 
Ss $ wee ene ee + 
$ INTI/INT2 $ KEYDESC : 
! DEVI/DEV2 } 
a 3 8 
: 
poe wenn een $ 2 ew nw on wn ee + 
f INTI/INT2Z { PHTXDBG»RMTXDBG ! 
t DEVI/DEV2 $ PSYXDBC»RSYXDBG | 
: t PJBXDBG»RJBXDBG | 
Se $ oe wen ne ne + 


procedure Se 


AO A ND aD allt END AD ANN A a AE NT A OE ON ND ON ED A SO eR ne eee 


Contains tink map of 
particular system 
createds where RMPXX 
RMPXX are the Production/ 
Recovery System Core 

Maos and PMPXXYY/RMPXXYY 
are the Productlon/Recove 
Job Tempi ate nabs: 
esateine VE generator 
directives for Dual 

State offset loads, 
Contains Keypoint 
descriptions for 

the Kaypoint report 
Program A RTISE Ys 

Contains deus tables 
produced by the linking 
of the system. 
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Each Velink of a 
Production/Recovery 
System Core/Job Temolate, 
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As required by system 
content or structure 
changes. 

Non-standard» bodates 

upon development's reauest. 
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Each Velink of a Production/ 
Recovery System Core/Job 
Template. 
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$ INTI/INT2 $ XLMMTR * Qbject text file 3} Each recompilation of a 
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H + execute in monitor ; 

H +; mode. ; 
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INTLISINT2 $ XLS113, DoJect text files ! Each recompilation of 


DEVI/DEV2 ¢ XLS133»XLS13D>» 
XLS1DD 


a system core 
module within these tibraries. 


of system core 
modules which run in 
Job mode and execute 
in ring le 


62a 20 £28 woG@ we 


a 2 +e ad eo ae we we wy >. > ab Oe oa we 
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: 
; H 
H ; 
: 
+ + 
INTI/INT2 $ XLJ2239XLJ236, 4 Object text Files +; Each recompilation of 
DEVI/DEV2 $ XLJ266sXLJ23D0» : of job template ‘ a job template 
+ XLJ2DD $ modules. +; module within these libraries. 
$ we wn eee $ ew eee ee ee eee $e ee ee ee ee ow eee en we $m ae we we a ww = + 
: INTL/ INT2 H XLIOSL» XLJLIB> ; Object text files ; Each reccmpllation of a ; 
$ DEVI/DEV2 $ XLJBBBsXLJOCM : of Remote Host» § module within these libraries. H 
H : XlJSG >; Interactives CITOII» 4 4 
H H : the Object Library : ; 
H H : Generators and various ; H 
; ; : user utility programs. H : 
$e cee ee nf we ee Oe ew wee meme } eee oe eee eee ew ee enn eee $ oe ee eo ee oe oe oe eo 
; INTI/SINT2 $$ PMTSTXX>» ; Outboard symbol +; Each Vetink of the : 
3 DEVI/SDEV2 $ PSYSTXXs $ tabte files for $ system. : 
H + RMTSTXX } Production/Recovery system ’ 
; $ RSYSTXX ; Monitors and Productions ; H 
; H + Recovery System Core } Hy 
H H $ produced by H : 
H ; § VELINK. ; 3 
foe ween enn $ eee ee ee ha ae ne ee ee $e en + 
j INTIS INT2 H PSY XX »P JBXXYY $ The Virtual envice § Each VELINK/VEGEN H 
+; DEVI/DEV2 $ RSYXXsRIBXXYY $} onnent files pro- ; of the system. H 
H H : duced by VEGEN. ; ’ 
$ ew ewe ne eee ooo $ ere oo ne on oo ee ee fm a a a ne + 
$ INTL + NOSTEXTsPSSTEXT $ A170 NOS system $ Each A17C NOS ipdabey. H 
$ Devil : SSYTEXT ; texts for current : H 
H : : NOS wet Shon. : ? 
$2 wwe een of ee nn oe oe $ a en oe ee ee ewe -<---— we fae ee ewe = + 
H ; H : : 
+ INTLSINT2 & XXM7KEY + Program to report i Non-standard ISWL ' 
: DEVI/pEV2 ! ! NOS/VE Keypoints t utility. : 
: ‘ + encountered during ' : 
; ; $ a simulation rune : : 
$ ww ew we we wnt ewe enn en oe ee we $e a a ee ee + 
: INTLI/INT2 ¢ XXM7DSI § NOS/VE deudevact ; NoneStandetds sipetied ; 
; ; ; file generator. ; by the ceqeet ers Eeoagers H 
$e en eee es $n ns oe oe ee i a a a a ee eee + 
$ INTI/INT2 $ XIDST»XMOD» § CYBER 180 PPU : Upon demand. ; 
$ DEVI/DEV2 $ XIDSPsXIHLP» + programs. : 3 
3 + XIRESsXSMA> H H ; 
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C1.0 BUILD CATALOG SETUP 


Before beginning the CYBIL compiler buildss perform the 
following setup process in the build catalog? 


1) GET,»PROCFIL/UN=LP3. 
SAVE» PROCFIL/CT=S aM=R, 


2) DEFINEsCYBPLIB/CT#S MR. 
ATTACHsSESPLIB/UN=LP3. 
COPY,SESPLIBsCYBPLIS,» V. 
RETURNsSESPLIBsCYBPLIB. 


3) Check that the PROFILE variable "PASSwWOR™ is defined» 
and set to the password of the bulld catalog. 


4) Check that the Deferred Satch job ltimit is set to 
UNLIMITED in the build catalog. 


Alt CYBIL build procedures are on the INT1 SESPLIB. They 
will) generally be runs howevers in a catalog ather than an 
official Integration catalog. Therefores all procedures 
outlined betow should be caiied via "“SESsINT1.<Procedure 
Name>™, or else add INT1 to the PROFILE variabte SEARCH tist 
in the bulld catalog. 


The general CYBIL build process is documented in the next 
section. The individual Procedures are documented iin 
subsequent sections. 
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C2.0 CYBIL_ BUILD PROCESS 


The various CYBIL compilers are built and tested in the 
following orders via the procedures indicated: 


BLDCC 1) Bulid the CC compiler front end and code 
generator; tink them together to form the 
CYBILC compiler; bulilld CYBCLIB. 

TESTCC 2) Test the execution of the CC compiter and 
CYBCLIB. 

CNYVRGCC 3) Test the CC compiler for convergence (i.e. 
can it compile itself and produce Identical 
binaries); rerun tests from 2) above, 

BLOCI 4) Build the CI code generator with the CYBILC 
compiler built in 1)-3) above; tink it with 
the common front end bullt in 1) above to form 
the CYBILI compiler. 

TeESTCI 5) Test the execution of the CYBILI compiler. 

BLDILI3 6) Bulld CYBILI3 with the CYBILI compiler built 
In 4) above; test the new CYBILI8B with 
CYBILI. 

RUNREG 7) Set up the environment for running the CI 
compiler regression tests and submit them, 

BLOIIS 8) Bulld and test the II compiler for the 
simulator, 

BLOIT2S 9) Build and test the [I OPT#2 compiler for the 
simulator. 

BLOIIH 10) Build the II conpiter for the hardware. 

RUNREG 11) Set up the environment for running the CI 
compiftter regression tests with the "OPT=2" 
option specified on the compiler calls», and run 
them. 


1)-6) must be run serially; 7)-10) may be run 
concurrentiy. 11) cannot be run until 7) has completed. 
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C3.0 CYBIL_ BUILD PROCEDURES 


Fach CYBIL bulld procedure that resides on the Integration 
SESPLIB is outtined below. Note that most procedures have a 
"CHAIN" parameter. If “CHAIN” is keyed on any one of the 
procedures, all subsequent procedures will be automatically 
submitted at the appropriate times in the order specified 
abovee This allows you to subnit af! build jobs by typing in 
onty one procedure call ("SES.BLOCC CHAIN"); it also allows 
you to restart the bulld process at any point should errors be 
discovered, 


Note also that the CC and CI procedures write status 
messages to the indirect access file CY8STS in the build 
catalog. This file can be interrogated on-fine or printed to 
obtain the results of the bullding and testing stages of these 
compifers,. The II compiter builds produce listings which must 
be checked to verify that the compilers were Indeed correctly 
built (see procedure descriptions below), 


C3.1 CC_ COMPILER BUILD_AND_TEST_eRanceOuURES 


C3.1.1 BLOCC PROCEDURE DESCRIPTION 


The SES procedure BLDCC bullds the CYBIL CC front end and 
code generator binary libraries (PFELIB and PCGLIB7s 
respectively) and then tJtinks them together to generate the 
CYBILC compiler. At the same times it recompiles the changed 
CYBCLI8 modules» saves them on an object file (CYBCO3J)»5 and 
REPULIB's them onto the existing SES version of CYBCLIB- to 
generate the updated CYBCLIS8, Status nessages are written to 
the file CYBSTS in the current catatog (BLDCC tis the only 
procedure which purges this file =F It exists; all other 
procedure append information to the end of the file). 


BLOCC creates the following permanent files in the build 
catalog: PFELIBs, PCGLIB7s CY38COBJ» CYBCLIB» CYBILC»s CMAP» 
CYBSTS. The format of the BLDCC is as follows: 


SES.BLDCC C m2 € (tist of) module name(s) > ] 
fe { ce J 
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{ chain 
{ local] 


m t The name(s) of the CC compiler modules to 
compite. The default Is to compile all cc 
compiler modules. 


fe ${ cc 3 Keyword indicating whether the modules specified 
by ™"M" are front end (fe) or code generator (cc) 
modulese This Keyword ts reguired if "M4" Is 
specified. 


chain 3 Option to submit subsequent CYB8IL build Jjobs 
after BLOCC comoletes. The default is to got 
submit these jobs. 


focal 2 Run BLDCC fn LOCAL mode. The default is to run 
it in BATCH. 


C3e1.2 CNVRGCC PROCEDURE DESCRIPTION 


The SES procedure CNVRGCC tests the CC compiter built by 
the BLDCC procedure for convergence, This means that the 
compiter must be able to compile itself, producing binaries 
identical to those which make it up. First it saves all the 
files created by BLDCC by copying then to files named by 
changing the first character of the file name to "A" (e.g. 
PFELIB => AFELIBs CYBCLIB -> AYBCLIB» etcede It then rebuilds 
the front ends code generators and CY8CLIB binaries with the 
CYBILC compiter built by the BLOCC procedures, generates and 
tests a new compiters and compares the new binaries to the 
previously bullt ("A"-prefixed) ones. If the binaries are pot 
identicals CNVRGCC makes a second attempt at convergence (this 
time saving the binaries on "B8"-prefixed files) and again 
compares the binary tibrartes. If the binarles verify, the 
job to build the CI compiter (BLOCI) is submitted; if they do 
pot verify after 2 attempts at convergences the procedure ends 
and the CYBIL project must be notified. Status messages are 
written to the indirect access file CYBSTS in the current 
catalog. 


CNVRGCC creates the following oermanent files in the build 
catatog: AFELIBs», ACGLIB7s AY3CO3J» aACYBILCs AYBCLIBs ACMAP 
(also BSFELIBs BCGLIB7s» BYSCOBJ» BCYSILC, BYBCLIBs BCMAP if 
convergence does not occur oan the first iteration). The 
format of the CNVRGCC is as follows? 
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SES.CNYRGCC € chain ] 
{ local j 


chain 3 Option to submit subsequent CYBIL build jobs 
after CNVRGCC comoietes. The default is to agqot 
submit these jobs. 


focal 3 Run CNVRGCC in LOCAL mode. The default is to 
run it in BATCH. 


C3e«ele3 TESTCC PROCEDURE DESCRIPTION 


The SES procedure TESTCC runs the CYBIL compiler tests 
SEQUENs EXITLP» and PPROC2 against the CYBILC compilers built 
by the BLDCC and CNVRGCC procedures. These tests reside on 
the test base TESTPL In the HAW catalog. Status messages are 
written to the indirect access file CYBSTS in the current 
catalog. 


TESTEC creates no new permanent files. The format of the 
TESTCC is as follows? 


SES.TESTCC € cnvg ] 
{ chain ]} 
{ focal ] 


cnvg ! Keyword indicating that the compiter being 
tested was built using the CNVYRGCC procedure. 
This parameter is needed to make the status 
messages written to CY8STS more meaningful. The 
default assumes that the CYBILC being tested was 
bullt by BLDOCC - i.e. it has not gene through 
convergence yet. 


chain 3 Option to submit subsequent CYBIL build jobs 
after TESTCC completes. The default is to gat 
submit these jobs. 


local 3 Run TESTCC im LOCAL mode. The dafautt is to run 
it in BATCH. 


C302 CI_COMPILER BUILD _AND_ TEST _PROCEOURES 
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C3021 BLDCT PROCEDURE DESCRIPTION 


The SES procedure BLDOCI builds the code generator binary 
library (PCGLIB8) for the CYBIL CI compiler. It then links 
this file with the common front end (PFELI8) produced by the 
BLDCC oprocedure to generate the CYBILI compiler. Status 
messages are written to the indirect access file CYBSTS in the 
current catalog» 


BLOCI creates the following permanent files in the build 
catalog: PCGLIB8,» CYBILIs»s CMAP8, The format of the BLDCI is 
as follows: 


SES-8LDCI {C m= < (fist of) module name(s) > ] 
{C chain J] 
{ local ] 


m 2 The name(s) of the CI code generator module(s) 
to be compited. The dafault is to compile all 
CI code generator modules. 


chain 2 option to submit subsequent CYBIL bulid jobs 
after BLDCI completase The default is to got 
submit these jobs. 


focal : Run BLDCI in LOCAL modee The default is to run 
it in BATCH. 


C3.2.2 TESTCI PROCEDURE DESCRIPTION 


The SES procedure TESTCI runs the CYBIL compiler tests 
SEQUENs EXITLPs and PPROC2 against the CYBILI compiler and 
CYBILIB (bullt by BLDOCI and BLDILIB, respectively). These 
tests reside on the test base TESTPL In the HAW cataloge 
Status messages are written to the indirect access file CYBSTS 
in the current catalog. 


TESTCI creates no new permanent files. The format of the 
TESTCI is as follows: 


SES.TESTCI C€ tib 
{ chain ] 
€C focal J 


fib 3: Keyword indicating that this run of TESTCI tests 
the CYBILIB built by BLDILIB. This keyword is 
needed to make the status messages written to 
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CYBSTS more meaningful. . The default assumes 
that this run of TESTCI tests the CYBILI 


compiler built by 3LOCI. 


chain : Option to submit subsequent CYBIL build Jobs 
after TESTCI conpietes., The default is to not 


submit these jobs. 


local 3 Run TESTCI tn LOCAL modee The defauit is to run 


it in BATCH. 


C3e2e3 BLDILIB PROCEDYRE DESCRIPTION 


The SES procedure BLDILI8 compiles the CYBILIB modules 
which have changed and saves them on the object file CYBIOBJ. 


It then GOL*%s them on the current SES version of CYBILIB 
generate the updated CYRILIS. BLDOILIB also creates 


to 


the 


CYBILGO file which is used in creating the version of CYBILIB 


which is used on the hardware (done in DS). Finatlys 


it 


resubmits the CI compiler tests (TESTCI with "LIB" option 
specified) which now use the new CYBILIS as a means of testing 
CYBILIB. Status messages are written to the indirect access 


file CY8STS In the current catalog. 


BLDILIB creates the following permanent files in the build 


catalog: CYBIOBSs» CYBILIBs CYBILGOs» LASRCSO, The format of 
the BLDILIB Is as follows: 
SES -BLDILIB € chain ] 
{C tocal Jj 
chain 3 Option to submit subsequent CYBIL build Jjobs 


after BLDILIB compietes. The default is to not 


submit more Jobse 


focal 3 Run BLDILIB in LOCAL mode. The default is 
run it in BATCH. 


C302e¢4 RUNREG PROCEDURE DESCRIPTION 


to 


The SES procedure RUNREG sets up the build catalog 
environnent to be able to run the CI compiler regression 


tests. The tests reside on an SCU test base PL in the 


HAW 


catalog. RUNREG first creates the alternate SCU base "MYBASE" 


in the build catalog which allows for the regression tests 


to 


be run from that cataloge I[t then submits the deferred batch 
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job which runs the tests (CY001.-CY999). To obtain the test 
resultss run 


SESsLPFN=C YBPLIB.RUNANL 


the morning after the regression tests are run. In order to 
run this erocedure,s, the deferred batch timit in the build 
catalog gust be set to UNLIMITEDs and the user must have the 
PROFILE varltable *PASSWOR" defined. 


RUNREG creates the folfiowing permanent files in the build 
cataiog: @MYBASE, CIDAY. The format of the RUNREG is as 
follows: 


SESeRUNREG [C€ opt2 ]j 
{ local ] 


opt2 3 Option to test the compiler with the OPT=2 
option. The default is to run the tests without 
the OPT=2 option. 


focal 3 Run RUNREG in LOCAL mode. The default is to run 
it In BATCH, 


C303 [TI_COMPILERS BUILO_AND_ TEST PROCEDURES 


C3-3e1 BLDIIS PROCEDURE DESCRIPTION 


The SES procedure BLDIIS builds the front end and code 
generator binary files (CYBIIFE and CYBIICGs respectively) for 
the II compiter for the simulator, and then tinks these two 
files together to produce the compiler checkpoint file (ITICPF) 
used as input to the simulator. It then submits a simulator 
test run of this compiter. The output of this test run 
consists of a compilation listing (which should contain nog 
compilation errors)s the simulator SESLOGs»: and a dayfile 
(which should atso show no compilation errors), 


BLOIIS creates the following permanent files in the build 
catalog: CYBIIFEs, CYBIICGs ITICPFs, LTIMAPs» SESLOGs LISTX. The 
format of the BLOIIS is as follows: 

SES.e-BLDIIS C€ local ] 


local ? Run BLOIIS in LOCAL mode. The default is to run 
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it in BATCH. 


C3.3.2 BLDII2S PROCEDURE DESCRIPTION 


The SES procedure BLDIT2S builds the front end and code 
generator binary files for thea [I OPT=2 compiler for the 
simulator (CYBI2FE and CYBI2CGs respectively), and then links 
these two files together to produce the compiler checkpoint 
file (I2CPF) used as input to the simulator. It then submits 
a simulator test run of this compiler. The output of this 
test run consists of a compilation fisting (which should 
contain po compilation errors)» the simulator SESLOG, and a 
dayfile (which should also show no compilation errors). 


BLOII2S creates the following permanent files in the build 
catalog: CYBI2FE»s CYBI2CGs I2CPF. I2MAPs SESLOGs LISTX. The 
format of the BLOII2S ts as follows; 


SESeBLDII2S € focal ) 


local 3 Run BLDII2S in LOCAL modee The default is to 
run it in BATCH. 


C3e323 BLOITIH PROCEDURE DESCRIPTION 


The SES procedure BLDIIH buillds the front end and code 
generator binary files (CYBHIFE and CYBHICGs respectively) for 
the II compiter binary that is used on the hardware. At the 
same tines, it generates the II hardware version of CYBILIB 
(CYB8HOBJ). It then takes these three files and some other 
miscellaneous routines and GOF's them together to create the 
UNCONVERTED and UNBOUND version of CY8IL II (CYBHBIN). 


BLOIIH creates the following permanent files in the build 
catalog: CYBHIFEs CYBHICGs: CYBHO8J» CYBHBIN, The format of 
the BLDIIH ts as follows: 

SES -BLOIIH C tocali J] 


focal 2 Run BLOIIWH in LOCAL modee The default is to run 
it in BATCH. 
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D1.0 KEYPOINIS 


Keypoints are used to give an execution time trace of 
program flow by showing that a given function is being performed 
(that Is» that a given procedure is being executed) » 

Keypoints may also be used to disptiay request parameterss 
status and error conditions. 


Dll ISGUING KEYPOINTS FROM CYBIL_CODE 


The general form of the keypoint instruction ist 


#INLINE (tkeypoint's keypoint_classs osk3m * datas keypoint_id); 


Dlelel KEYPOINT CLASSES 


A keypoint is identified by both class» and identifier. 
The following deck explains the partitioning of the keypoint 
classese 


OSDKEYS 
COMMON 


CONST 


{ Keypoint Classes 2? 

{ 

{ The 16 keypoint classes supoorted by the hardware are 

{ partitioned between the Systens Product Set and User as follows. 


osk$system_class = © { 0 «+ 5 }y» 
osk$product_set_class = 6 { 6 ec 10 Fy» 
osk$user_class = 11 { 11 oc 14 Fy 
osk$pmf contro! = 15; 


CYBIL Installation Documentation 


p1-2 


05/22782 


Object Text Files 


D1.0 


Dll. 


KEYPOINTS 
1 KEYPOINT CLASSES 


PO PEPE IO OO O8 EOE 08 TE PE 8 OE 88 88 88 08 OE TE 96 FE PE PE 08 8 PE PE OR TE P88 RE 8 8 8 28 0 0 ne FO OE DOE F828 00 FE FE PE PE 28 P08 E98 PE PO RE PE PE ME OE PE PEO 


et cing pet ty ay pring pty tag iy py ping pag poly ity tiny tg pty 


Keypoint Multiplier: 


By conventions 
the 32 bit keypoint ‘code supported by the hardware 
is split into two fields. The right field contains a keypcoint 
identifier which is used to identify a function within a 
keypoint class. For examples if a particular keypoint class 
represents exit from a procedures 
then the keypoint identifier night identify exit from 
procedure A versus exit from procedure Be 

The teft fleld Is used as a data parameter appropriate to the 
function identified by the keyooint identifier. In the 
procedure exit example aboves 
the data parameter filelid might be used to Indicate the 
status of the procedure call, 

The keypoint multiplier is used to partition the keypoint 
code into the two fields. The data parameter should be 
multiptied by the keypoint multipittier to prevent it from 
overtapping the keypoint identifier field. 


CONST 
osk$m = 4096; 


Dl.ele2 NOS/VE KEYPOINT CLASSES 


Five keypoint classes named ENTRY,» EXITs UNUSUAL» DEBUG» 


and DATA are defineds taking five of the available sixteen classes 
by the hardware, 


ENTRY = Every gated procedure pilus all major internal procedures 
{those shared across functional areas) should contain a 
keypoint of this class. These keypoints should be placed 
as close as possible to the entry to the procedure. 


EXIT - Every gated procedure plus ail major internal procedures 
(those shared accross functional areas) should contain a 
keypoint of this class. These keypoints should be placed 
as closed as possible to the exit to the procedure. 


UNUSUAL = Every situation which is unexpected or quite unusual 
should contain a keypoint of this class. It is intended 
that these keypoints would be enabled at all times. The 
frequency of encountering these keypoints SHOULD BE 
very low. The DATA keypotnt class is not alftowed in 
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conjunction with a keypoint of class unusual. 


DEBUG = These keypoints are for providing additional trace 
information as an assist in debugging hardware or software 
Problems. DEBUG class keypoints would be most useful in 
the more complex areas of the system. 


DATA - This keypoint class can be used with ENTRY» EXITs and 
DEBUG keynooints for the gathering of extra data. Ail DATA 
keypoints encountered are suoptying additional data which 
will be associated with the fast ENTRY» EXITs or DE8UG 
keypoint. 

DATA keypoints should be used with care since the PMF 
hardware can only buffer up 16 keypointss keypoint cluster 
can cause lost keypoints. 


The following deck defines the NOS/VE OS class constants. 


OSDKEYC 
COMMON 
{Define KEYPOINT CLASS Codes. 


CONST 
osk$data = osk$system_ class + 0» € 9S =- DATA keypoint} 
osk$unusual = osk$system_class + l» {U OS - Unusual keypoint.} 
osk$entry * osk$system_class + 2» {& OS - Entry keypoint)} 
osk$exit = osk$system_class + 35 €X OS =- Exit keypoint} 
osk$debug = osk$system_class + 43 {0 OS - Debug keypoint.} 


{*callcsosdkeys 


D1.1.3 KEYPOINT DATA AND IDENTIFICATION 


Upon successful execution each keypoint instrucion will 
provide a total of 32 bits of information. OQur convention uses 
12 bits of this for keypoint identification and the remaining 20 
bits as user supplied data. Try to use this 20 bits to supply 
meaningful Information (taskids segment number, file identifiers 
queue lengths, page numbers, times etc.). The keypoint 
identification codes are defined in the attached common deck. (Gn 
DATA class keypoints the data b2@tongs to the previous keypoint 
and the full 32 bits is available for additional user data. 
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Dl.1le4 EXAMPLE ISSUING KEYPOINTS 


ENTRY keypoint with data: 


#INLINE(@*keypoint"», osktSentry, osk3m#taskid.indexs 
tmk$exit task) 3 


UNUSUAL keypoint with no data: 
#INLINE (tkeypoint's osk$Sunusuals J» mmk$no_memory); 
ENTRY keypoint with extra data? 


#INLINE (tkeypoint's osktentrys osktm * segment _ number » 
mmk$ page fautt)3 
#INLINE ("keypoint's osk#datas offsets 0)3 


D115 KEYPOINT IDENTIFIERS 


Each area of the operating system has been given a range of 
identifiers to use for keypointse The base for each area is 
defined on common deck OSDKEYD. Each area should 
haye a deck xxDKEY (where xx is the product identifier) 
where the areas keypoint constants are defined(e.getmktexit_task). 
Please reference the section on keypoint description decks» for an 
example of one of these decks. 


OSDKE YD 
COMMON 
{This deck defines constants for use with KEYPOINTS. 


{Define base keypoint procedure identifiers for each area of the 
{O0S. 


CONST 
amk$base = 100» {10 - 149} 
bak$base = 200,» {200 - 249} 
clk$base # 250» {250 - 299} 
cmk$base = 3060,» {300 - 349} 
dbk$base = 350, {356 - 399} 
dmktbase = 400,» {400 - 549} 
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Fmk$base = 5505 {550 - 599} 
ick}base = 600,» {600 ~- 649} 
ifkSbase = 650,» {650 - 699} 
fik$Sbase = 700» {700 - 749} 
ink$base # 750, {750 - 799} 
jJmk$base = 800, (800 — 849} 
Igk$base = 850, {856 - 899} 
1ikSbase = 900, {900 - 949} 
fok$base = 950,» (£950 - 999} 
fuk$base = 1000, {1000 - 1049} 


mik$Sbase = 1050, €1650 ~- 1999} 
mmk$Smonitor base = 1100.5 {1106 - 1149} 
mmk$ job base = 1150, £1150 - 1199} 
msk$base = 1200s {1209 - 1249} 


mtk$base # 1250, £1250 - 1299} 
ock$base = 1300» {1300 - 1349} 
ofk$base = 1356» £1350 - 1399} 
osk$base = 1400,» {1400 - 1449} 
pfk$3base = 1500» £1500 - 1549} 
pmkSbase = 1600» {1600 - 1599} 
rhk$base # 1750, {1755 - 1799} 
srk$base = 1800,» {£1800 - 1819} 


stk$base = 1850, {£1850 ~- 1899} 
tmk$monitor base = 1900s {1900 - 1949} 
tmk$ job base = 1959» {1955 - 1999} 
Jsk$monitor_ base = 2000» (2000 - 2049} 
isk$job_base = 2050, £2050 - 2099} 
avkSbase = 21005 {2160 - 2149} 
sfkBSbase = 2150,» (2150 - 2199} 
lok$base = 2200» {2200 - 2249} 
rmk$base = 2250, {2250 - 2300} 
mtkSassembiy_language_base = 40003 £4000 - 4095} 
{ 0S assembly language 4900 - 4095} 
{*callicsosdkeyc 


D1e2 COLLECTING KEYPOINTS 
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D1.2.1 ON THE SIMULATOR 


When executing on the simulator all keypoint instructions cause 
an entry to be added to the tocal file SESSMKF. 


D1le2e2 ON THE HARDWARE 


Software keypoint collection is availabie for collecting system 
and job keypoints. System keypooints are those keypoints in the 
entire system and job keypoints are only those dealing with a- 
particular job.» Only one system keypoint collector 
can be active at one times but 2ach job may have an active 
job keypoint collector, Software keypoints are collected on a 
file lftocal to the job in which the keypoint collection task Is 
running. After keypoint collection is terminated this file can 
saved on the 170 side and analyzed by the keypoint analyzer. 


Three commands are supplied to utilize the keypoint feature? 
KEYONs KEYOFFs, and KEYPOINT. 


D1.2.2.-1 KEYON command 


The KEYON command initiates keypoint recording and collecting. 
It has the form of? 


KEYONsrecording_modes environments kmmsy kmijy» 
keypoint class starts keyopoint_class_ stops 
keypoint file names keypoint_buffer_size, 
coltector_timeout_period 
recording_mode = "software! or '‘hardware's default is software 
environment = tjob* or system!’ » default is job 
keypoint_mask_monitor = 0 of OIFFFFI16) » default is OfFFfFF(16) 
keypoint mask job = 0 « OFFFFI(15) » default is OffFFF(16) 
keypoint_cltass_start = 0 .. 15 


This specifies that keyooint collection should not 
start until a keypoint of this class in encountered, 
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defauit is to bagin coltfecting immediately. 
keypoint uctass_stop = 0 .. 15 

This specifies that keypoint collection should stop 

when a keypoint of this ciass is encountered. 


keypoint file_name = file name on which keypoints are saveds 
used with software keypoints onlys default is KEYFILE. 


keypoint buffer _size = 0 .. halfword » default is 269¢ 
For software keypoints onty. 


coltector timeout period = 0 «2 halfword » default Is 50 


mitiiseconds. 
For use with software keypoints only. 


D102+2e2 KEYOFE cosmand 


The KEYOFF command terminatas keyooint collection. 


KEYOFF= environment 


D1..26263 KEYPOINT command 


This command is used to issue keypoints. 

KEYPOINT s keypointiclass_numbers keypoint_code 
keypoint_class_number = 9 ». 15 » default is 15 
keypoint_code = 6 «. halfword » default is 0 


After keypoint collection Is terminated the keypoint files 
can be saved on the 170 by a REPLACE_FILE with 856 
conversione For example, 

REPLACE Filtskeyfileskeyfilesb56 


On the 170 side this can be analyzed by using NVEKEY» 
format = HOW. 
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01.3 KEYPOINT_ANALYZER_UTILITY 


D1le301 NVEKEY 


The SESSMKF file produced on the simutators or the 
KEYFILE produced on the hardware can be reformatted into a 
readable fisting by executing the following procedure, 


SESe-NVEKEY CKPF2 ] CFORMAT= } (KD J] CAREA® J 

NVEKEY creates a simulator generated keypoint trace file. 

The “kpf" parameter Is the keypolInt file used as input. 

The "kd" parameter is a file or list of files which define(s) 
the keypoint descriptions. 


wm-=-=P ARAMET E Rem —-DEFAUL T------- “ALLOWABLE VALUE S------ 
kof SSESSMKFE!? file name 
*KEYFILE® if format#HDw 
fornat *SIM! simshdw 
kd MKEYDESC! file name(s) 
area EUSERE user name 


If run interactivelys when the procedure terminates the 
reformatted listing Is on tlocajl file KEYFILE. 


D1.3e2 KEYPOINT DESCRIPTION FILE 


The keypoint descriptions are used by the keypoint 
analyzer utility to direct the reformatting of the 
keypoint information. 
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D1.3.2.1 keypoint decks 


Each area has a keypoint constant deck xxDKEY (where xx 
is the product id), The keypoint descriptions are now 
included in this deck immediately following the keypoint 
constants (similiar to the message templates). 


Each description has the following format. 
Note? e@ach element (if given) Is positionally dependant. 


{CLASS CSUBLIOLFIELDI] KEYPOINT_LASEL CDATA_LABEL] CDATALFIELD] 


CLASS of keypoint = required 
E Entry 
X exit 
jy Unusual 
D Debug 


SUBLID_FIELD — optional ~ (described tater) 


KEYPQOINT_LABEL - required - This is a string that 
describes the purpose of the keypooint. 


DATA_LABEL ~ optional ~- This is a string of up to 8 
characters describing the data portion of the keypoint. 


DATALFIELD_DESCRIPTOR = optional - This consists of data 
fornat and ftength. 
data_format 


H Hex 
I Integer (decimal) 
A ASCII 


Concatenated to this is the tength of the data portion of 
the keypoints in decimal! bits. 
For example: 1I29 


DleZe2elel EXAMPLE KEYPOINT DECK 


STDKEY 
COMMON 


{ PURPOSE: 
{ This deck contains ail of the set manager keypoint constants. 


CONST 
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stk$create_set = stk#base + ly, 
{E ‘'stp$create_set! ‘ring ' H } 
{X ‘'stp$create_set!? 'status ' I20 } 


stk$eurge_set = stk¢base + 2,5 
CE "*stp$purge_set! } 
{X "sto$purge_set! tstatus * 123 } 


stk$cantidm_store_set_ord = stkthbase,» 
CU "cant dmp$store_avt_set_ordinal!? tavtindx * H20 } 


stktof_root size = stk$base + 53 
{0 ‘'pflroot_size® 'rootsiz § H20 } 


7? PUSH (LIST := OFF) 2? 
{*calle osdkeyd 
27? POP 2? 


D1.32.2.122 SUBLIDLFIELD 


This optional fieid allows a means of subdividing a single 
keypoint into several! descriotors. The particular descriptor 
is chosen on the basis of a selectable number of bits of the 
data field. This fietd has the following format? 


SUB_ID_LENGTH. SUB_ID_MATCH 


SUBLIDLLENGTH - This specifies the number of bits (right most) 
of the data field to uses to deternine which 
descriptor to choose, 


SUB_LID_L MATCH =~ This specifies the integer identifier used to 
match the data portion. 


Example: 
mmk$page_ fault = mmk$monitor_base + 6» 
{E *page fault processor? } 
{E 401 "Page found In avail queue’ tpftl * 16} 
{E 4.2 Page found in avail modified queue * 'pfti * H16} 


If this keypoint was issued and produced data of 2s the 
descriptor with the sub_id match field of 2 would be 
used ("page found in avail modified queue’ ), 
These keypoints were issued with a subLid_length * 4» 
thus the 4.x. For example: 
#INLINE (tkeypoint'ts osk$entry, osktm * 

(pfti * 16 (2 ** sub_id length} + 2{sub_id_match})>» 
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mmk $page_fault); 


D1.3.2e2 generating the descriptor file 


The keypoint descriptions area keot on a file called KEYDESC 
on the integration cataloge This file may be produced by? 


SES «GENCOMP MBOSMKEYS ABS((NOSVEPL sOS5LPIsINT2)) CFEKEYDESC 


The user may add keypoints to her xxDKEY deck locally» and 
the KEYDESC fille may be produced as aboves specifying the 
additional toca! bases. The KEYDESC file may then be saved 
on her catalog. 


If new keypoint decks are addeds *callic 's to these new decks 
choyld be added to the deck OSMKEYS»s and the anpropriate 
base constants added to deck OSOKEYD. 


When transmitting changes to keyooint deckss be sure to Inform 
integrations via the transitta!l forms, to recreate the file 
KEYDESC. 


01.32263 oasmkeys_forcmrat 


This section will onty be usaful to those desirina to add 
additional keypoint classes» keypoint class base constants» 
or new keyooint description decks. 

The classess identifierss and descriptions are each buffered 
by a comment. For examples to add another keypoint class: 
{$$$ START KEYPOINT CLASSES $3} 
CONST 

psk¢$entry = osk$product_set_ctass + 13; {££ PS - entry keypoint} 
{$$$ END KEYPOINT CLASSES 433 } 
note: The — follwoing the "{" wil! be used in the description. 


This new section should be appended to the end of the KEYDESC 
file. Readers desiring more information should reference the 
attached BNF» and the attached decks OSMKE YS. 


The foilowing represents a sampie of how to set up 
the description module, 
Note: Comment put around *call for sake of documentation only. 
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DSMKEYS 

2? LEFT t= 1» RIGHT t# 110 2? 
MODULE keypoint_description_ file; 
{*callcsoasdkeys 

{$$$ START KEYPOINT CLASSES 333} 
{*callcsosdkeyc 

{$$$ END KEYPOINT CLASSES $$} 
{$$$ START KEYPOINT IDENTIFIER S8ASES $33} 
{*catlcsosdkeyd 

{$$$ END KEYPOINT IDENTIFIER BASES $33} 
($$$ START KEYPOINT DESCRIPTIONS 843%} 
{*¥catlcs amdkey 

{¥*¥callcsbadkey 

{*caltlcs cidkey 

{*callcscmdkey 

{*callcsdbdkey 

{*calles dmdkey 

{*caltcs fmdkey 

{*callesicdkey 

{*calicsifdkey 

{*callcsliidkey 

{*catlcsindkey 

{*callcs jmdkey 

{*callcsigdkey 

{*catleoslidkey 

{*caltcstodkey 

C*calics ludkey 

C*callcsmidkey 

{¥*¥calicsmmdmkey 

{*calleosmmd jkey 

{*callcsmsdkey 

{*calltcsmtdkey 

C*¥callesocdkey 

{*callesofdkey 

{*callesosdkey 

{*callcsofdkey 

{*caltcs pmdkey 

{*callcsrhdkey 

{*callessrdkey 

{*callcsstdkey 

{*callcstmdmkey 

{*callcstmd jkey 

{*calles Jsdmkey 

{*caltes isdjkey 

{*caltcsavdkey 

{*callcssfdkey 

C*callesiodkey 
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{*callcsrmdkey 
{$$$ END KEYPOINT DESCRIPTIONS $39} 
MODEND keypoint _description_file;3 


D1.4 REEORMATIEN EILE_ DESCRIPTION 


The output from procedure NVEKEY Is a file called KEYFILE. 
This reformatted listing contains two sections. The first 
section is a ltisting of all the keypoints in the order they were 
issued. The second section is qa summary of the number of times 
each keypoint occured. 

Each tine in the first section has the following format; 


RT TSL DATA DATA_LLABEL S TN AREA_ID KP_LLABEL 


The RT field designates the value of the free running 
microsecond clock (time since deadstart) when the keypoint was 
executed, On the simulator the ciock is incremented by 1 for 
each Instruction axecuted. 


The TSL fieitd designates the time (microseconds) since the 
fast keypoint instruction was executad, 


The DATA Fleid specifies the value of the data portion of the 
keypoint in the format described in the keypoint description 
file for this keypoint. 


The DATA_LABEL fleld Is the data label fleld from the 
keypoint description file for this keypoint. 
This identifies the data being displayed. 


The S$ fletd specifles the state of the machine when the 
keypoint was issued and is one of the following: 


M =—- Monitor mode 
J - Job mode 
\ 
An * preceding the S field indicates that 
trap processing is actives that is the trap handler has 
been entereds but not exited. 


The TN Fietd gives the global task id of the task that 
was executing when the keypoint was issued. 
The system is task l- 
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The AREA_ID fieid is the area Identifier for the area 
issuing the keypoint. 


The KP_LLABEL is the keypoint tabel fietd from the kaypoint 
description filee This describes the keypoint. 


NOTE? For an undefined keypoints that Is» one which has no 
descriptor entry» the area _id fFleld contains the 
Integer for the keypoint class» the class field 
on the output is specified as "UND™s and the KP_LABEL 
becomes the id number of the kaypoint. 


D1.5 BNE_KEYPOINT. DESCRIPTION 


<analyzer_descriptor_input> %t= <keypoint_class_allocation_deck> 
{[ <definition _deck> eee ] 


<keypoint _class_allocation_deck> %3= <cybil code and/or comments> 
{ <class _base_definitions> «es. J 
<cybil code and/or comments> 


<class _base_definitions> = <class _base_id> <spce> = <spe> <based 


<class _base_id> %3:2= oskf$system_class ! osk$product_set_class : 
oskfuser_class } osk$pmf_control 


€spe> 332 € <spaced> eee J 
€base> 2*32 <integer> 


<definition _deck> %:3= <class definition _deck> $ 
<base_definition _deck> 3} 
<keypoint definition _deck> 


<class _definition _deck> %:2 {$$$ START KEYPOINT CLASSES 33%} 
<cybil code and/or comments> 
{[ <class _definitions> ees Jj 
<cybil code and/or comments> 
{#38 END KEYPOINT CLASSES $34} 


<class_definitions> t:= <keypoint_class> <spc> = <spc> 
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<class _base_id> <offset> 
{ <keypoint_class_id> <cybil comment> 


<keypoint.class> ::= <identifier> 
Coffset> tt2 + <spo> <integer> <delimiterd 
<delimiter> t2=2 , } 3 
<Ckeypoint _ctass_id> %32 <character>D 
<base_definition_deck> t= 
($$ START KEYPOINT IDENTIFIER BASES £%$3} 
<cybil code and/or comments> 
{ <range_base_definitions> ews. J] 
€cybil code and/or comments> 
($33 END KEYPOINT IDENTIFIER BASES $€3$} 


<range_base_definitions> %:2 <keynooint _base> <delimiter> 
<base_range> 


<keypoint_base> %3= <spe> <base_id> <spce> = <spcd> <base> 
<base_id> %32 <identifier> 
<base_range> 232 <spe> { <low _base> <sp> —- <high base> C€ }.] 
<low_base> tt2 <integer> 
<high_base> %%=z <integer> 
<keypoint definition deck> t= 
€3$% START KEYPOINT DESCRIPTIONS 8%} 
<cybit code and/or comments> 
{C <xxdkey_deck> eee ] 
<cybil code and or comments>d 
{$3h END KEYPOINT DESCRIPTIONS 433} 


<xxdkey_ deck> :3= (€ <cybil code and/or comments> J] 
C <keypoint_info> es. |] 


<keypoint_Info>d t:= <keypoint_constant_line> <delimiter> <eol>d 
{C <keypoint_descriotor> es. |] 
[ <blank lines> J] 


<keypoint _constant_line> 232 <keypoint_constant> <spc> = <spe> 
<keypoint_base> <spe> [€ <offset> 1] <spcd 
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<keypoiInt_constant> %%:= <identifier>d 
<keypoint _base> 2:2 <identifier> 


<keypoint descriptor> 2:2 { <keypoint_descriptor_list> <spe> € } 1 
<eal> 


<keyopoint descriptor _fist> *%%= <keypoint class_id> <spe> 
C <special_case_code> J] <spe> 
C <subLid_field> 1] <spe> <keypoint_label> 
€sope> € <data_fieid> }j 


<special_case_code> t= MiNi $ :T 
(M = Mtr» N = Noss S = task Switchs and T = Trap) 


Csub_-id fieid> 32 <sub_id_fength> . <sub_idumatch> 
€subLid-tength> 332 <fieltd_length> 

<fletdilength> t:2 0.2.52 (in bits) 
<sub_idumatch> 3238 <small_integer> 

<smalllinteger> 222 0.2.0 FFFFFFFFFFFFF (16) 

<keypoint_label>d 332 <label> 

<label> sss " <character_string> ! 

<character_string> %32 any visible characters except ! 
<data_fieid> tt=2 <data_label> <spce> € <data_field descriptor> ] 
<data_label> %2= <label>d 

<data_fileld udescriptor> %t3= <data_format> [€ <data_fieldltength ] 


<data_format> 232 A $ H i I 
(A = Alphanumerics H = Hexs, I = Integer) 


<data_field_tength> t22 <field length 


(NOTES <sub_idiftength> + <data_field_length> must he <= 52 bits ) 
(NOTE? operating system <keypoint_class_id> = {DsE»UsX}) 

(NOTE? <keypoint _ciass_id> for any keypoint used for 

additional information to previous keypoints 

must be a space) 

{NOTE a <definition_deck> remains itn effect until 
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superceeded by a deck which redefines the 
area to which it pertains) 


i 
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